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ing  system  from  the  vantage  point  of  current  and  future  support  requirements, 
addressing  the  AFGWC  data  processing  system  over  the  1977  through  1982  time 
frame.  This  study  was  performed  under  a unique  plan  which  allows  complete 
traceability  between  user  requirements,  Air  Force  Global  Weather  Central 
operational  functions,  requirements  levied  upon  the  data  system,  a proposed 
component  configuration  which  meets  the  data  system  requirements,  and  a system 
specification  designed  to  acquire  a system  which  meets  these  requirements. 

The  resultant  system  described  has  a number  of  unique  features,  including 
total  hardware  authentication  separation  of  security  levels,  load 
leveling  accomplished  by  assigning  main  processors  in  accordance  with  a dynamic 
priority  queue  of  tasks,  and  a system-wide  network  control  capability.  Other 
key  features  include  a central  data  base  processor  to  fill  requests  for  data 
from  other  processors,  computer  operations  centers,  the  use  of  array  processors 
for  accomplishing  difficult  numerical  problems,  and  sophisticated  forecaster 
console  support.  These  elements  have  been  designed  to  provide  99. 5%  reli- 
ability in  meeting  user  requirements. 

The  proposed  system  architecture  consists  of  five  dual  processors  each  of 
which  is  about  3.5  times  as  powerful  as  an  existing  AFGWC  processor 
(a  Univac  1108).  Each  dual  processor  has  an  array  processor  which  will  be 
capable  of  very  high  performance  on  vector  arithmetic.  The  array  processors 
are  used  to  assist  on  the  difficult  numerical  problems,  including  the 
Advanced  Prediction  Model  for  the  global  atmosphere, as  well  as  very  fine  grid 
cloud  models  and  cloud  probability  models.  Some  of  the  new  requirements  that 
will  be  supported  with  this  system  are  a one  minute  response  to  query 
interface,  reentry  support  for  Minuteman,  and  limited  processing  of  high 
resolution  (0.3  nautical  mile)  meteorological  satellite  data.  In  addition, 
cloud  cover  prediction  for  tactical  weapon  systems,  ionospheric  prediction 
for  radio  frequency  management,  and  defense  radar  interference  prediction  will 
be  supported  by  this  system. 

Volumes  of  this  final  System/Subsystem  Summary  Report  are  as  follows: 

Volume  1 - Executive  Summary 


Volume  2 
Volume  3 
Volume  4 
Volume  5 
Volume  6 
Volume  7 
Volume  8 


Requirements  Compilation  and  Analysis  (Parts  1,  2,  and  3) 
Classified  Requirements  Topics  (Secret) 

Systems  Analysis  and  Trade  Studies 
System  Description 
Aerospace  Ground  Equipment  Plan 
Implementation  and  Development  Plans 
System  Specification 
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ABSTRACT 


This  document  has  been  prepared  in  partial  fulfillment  of  CDRL  line  item 
A004  of  System  Development  Corporation's  Air  Force  Global  Weather  Central 
System  Architecture  Study  contract.  Efforts  for  this  report  were  expended 
under  Task  6,  "Conceptual  Design  and  Development  Plan",  performed  under 
contract  F04701-75-C-01 14  for  SAMSO,  under  the  direction  of  Col.  R.  J.  Fox, 
YDA. 

The  purpose  of  this  study  has  been  to  optimize  the  entire  AFGWC  data 
processing  system  from  the  vantage  point  of  current  and  future  support 
requirements,  addressing  the  AFGWC  data  processing  system  over  the  1977 
through  1982  time  frame.  This  study  was  performed  under  a unique  plan 
which  allows  complete  traceability  between  user  requirements.  Air  Force 
Global  Weather  Central  operational  functions,  requirements  levied  upon 
system  requirements,  and  a system  specification  designed  to  acquire  a 
system  which  meets  these  requirements. 

The  resultant  system  described  has  a number  of  unique  features,  includ- 
ing total  hardware  authentication  separation  of  security  levels, 
load  leveling  accomplished  by  assigning  main  processors  in  accordance  with 
a dynamic  priority  queue  of  tasks,  and  a system-wide  network  control 
capability.  Other  key  features  include  a central  data  base  processor  to 
fill  requests  for  data  from  other  processors,  computer  operations  centers, 
the  use  of  array  processors  for  accomplishing  difficult  numerical  problems, 
and  sophisticated  forecaster  console  support.  These  elements  have  been 
designed  to  provide  99.5%  reliability  in  meeting  user  requirements. 

The  proposed  system  architecture  consists  of  five  dual  processors  each  of 
which  is  about  3.5  times  as  powerful  as  an  existing  AFGWC  processor 
(a  Univac  1108).  Each  dual  processor  has  an  array  processor  which  will  be 
capable  of  very  high  performance  on  vector  arithmetic.  The  array  processors 
are  used  to  assist  on  the  difficult  numerical  problems,  including  the 


i 


i I A. ' ,1  ..  i.  II  MM 


wmmmmm 


Advanced  Prediciton  Model  for  the  global  atmosphere,  as  well  as  very  fine 
grid  cloud  models  and  cloud  probability  models.  Some  of  the  new  requirements 
that  will  be  supported  with  this  system  are  a one  minute  response  to  query 
interface,  reentry  support  for  Minuteman,  and  limited  processing  of  high 
resolution  (0.3  nautical  mile)  meteorological  satellite  data.  In  addition, 
cloud  cover  prediction  for  tactical  weapon  systems,  ionospheric  prediction 
for  radio  frequency  management,  and  defense  radar  interference  prediction 
will  be  supported  by  this  system. 

Volumes  of  this  final  System/Subsystem  Summary  Report  are  as  follows: 

Volume  1 - Executive  Summary 

Volume  2 - Requirements  Compilation  and  Analysis  (Parts  1,  2,  and  3) 
Volume  3 - Classified  Requirements  Topics  (Secret) 

Volume  4 - Systems  Analysis  and  Trade  Studies 
Volume  5 - System  Description 
Volume  6 - Aerospace  Ground  Equipment  Plan 
Volume  7 - Implementation  and  Development  Plans 
Volume  8 - System  Specification 

This  volume  presents  a design  development  and  logistics  schedule  in  section 
1.0,  and  discusses  implementation  aspects  of  the  architecture  in  various 
stages  from  a 1977  baseline  through  mid  1979.  Included  in  this  section  are 
software  topics,  as  well  as  hardware,  personnel,  and  facilities  topics. 
Time-phased  system  architecture  costs  are  presented  in  section  2.0  for 
all  components  of  the  architecture  domain,  while  a detailed  data  system 
risk  analysis  is  given  in  section  3.0.  Section  4.0  presents  various  aspects 
of  the  validation  and  verification  of  the  proposed  data  system,  including 
hardware  and  software  topics. 
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RELATIONSHIP  OF  VOLUME  STRUCTURE  TO  DOMAIN 


The  required  content  of  this  document  made  its  structure  unsuitable  for  close 
conformation  to  either  the  architectural,  functional,  characteristic,  or 
requirements  domains.  Of  the  three  topics  discussed  however  [(1)  Design 
Development  and  Logistics  Schedule,  (2)  System  Cost  Considerations,  and 
(3)  Risk  Analysis],  thc^e  is  structural  resemblance  to  the  architectural 
domain  through  a portion  of  the  first  two  of  these  topics.  In  the  first 
section,  paragraphs  1.1,  1.3,  and  1.4  involve  architecture  components  A10-60, 
A70,  and  A90  respectively  with  1.2  then  focusing  in  more  detail  on  software 
(A30.2-30.4).  The  second  section  dedicates  paragraphs  2.3,  2.4,  and  2.5  to 
A10-A60,  A70,  and  A90  respectively.  The  third  section  and  the  remainder  of 
the  first  two  are  concerned  with  topics  either  not  related  to  the  domain 
structure,  or  are  general  in  nature  such  that  they  correlate  to  all  aspects 
of  the  domains. 

To  establish  traceability  between  the  Implementation  and  development  plans 
and  the  rest  of  the  architecture, we  have  defined  an  implementation  plan 
"domain"  whose  components  are  made  up  of  groups  of  related  hardware,  software, 
personnel,  and  facilities  or  concepts  involved  with  preparing  them  for  imple- 
mentation. The  elements  are  listed  in  detail  as  "activity  codes"  in  tables 
2 through  5.  The  location  in  this  volume  of  the  discussion,  schedules,  and 
costs  involved  with  the  implementation  plan  "domain"  are  pointed  out  in  the 
following  table  entitled  "Applicable  Domain  vs.  Paragraph  Numbers".  Finally 
the  correspondence  between  the  implementation  plan  domain  and  the  architec- 
tural domain  is  established  in  the  second  following  table  labeled  "Volume/ 
Domain  Relationships". 
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1 .0  DESIGN  DEVELOPMENT  AND  LOGISTICS  SCHEDULE 


i 


The  structure  of  this  discussion  of  implementation  schedules  is  roughly  designed 
to  follow  the  format  established  by  the  architectural  domain  including:  data 
storage,  data  transfer  and  routing,  computation  and  software,  terminal  inter- 
face, consoles,  and  data  input  and  display  (architectural  domain  components 
A10-A60).  These  are  discussed  collectively  in  Section  1.1.  The  discussion 
is  chronological,  starting  with  an  assumed  baseline  in  early  1977  and  running 
through  the  full  implementation  of  the  new  system  in  mid-1979.  Because  of  the 
importance  of  software  (A32-A34  of  the  architectural  domain)  on  this  schedule, 
it  is  given  special  treatment  in  Section  1.2.  Two  more  of  the  elements  of  the 
architectural  domain,  personnel  and  facilities  (A70  and  A90  of  this  domain) 
are  introduced  in  Sections  1.3  and  1.4,  respectively.  The  only  aspect  of  the 
architectural  domain  omitted  was  management  (A80),  since  it  only  has  an  implicit 
bearing  on  the  implementation  schedules.  Section  1.5  concludes  this  discussion 
with  a summary  of  activity  schedules  which  have  been  developed  for  input  to 
automated  network  scheduling  and  analysis  systems.  1 

1.1  TOTAL  SYSTEM  ARCHITECTURE  AND  PHASEOVER  SCHEDULE  (A10-A60) 


The  driving  factor  in  determining  the  timing  for  an  implementation  plan  for  the 
enhanced  AFGWC  architecture  is  the  schedule  associated  with  established  require- 
ments. In  order  to  meet  these  requirements  according  to  the  exact  specifica- 
tions established  by  the  Air  Force,  certain  reliability  levels  must  be  met  and 
maintained.  To  satisfy  a given  requirement  and  its  reliability,  certain 
hardware  components  become  necessary  by  specific  deadlines  and  the  implemen- 
tation plan  is  established.  A brief  discussion  of  reliability  at  this  point 
will  help  to  establish  it  as  this  link  between  requirements  and  an 
implementation  schedule. 


In  analyzing  user  requirements,  SDC  has  found  the  specification  of  97%  and  95% 
reliabilities  (assurance  of  delivery  of  the  product  on  time)  associated  with 
USAFE  and  WWMCCS  requirements  which  become  operational  in  mid  1978.  There  are 
many  factors  which  enter  into  the  successful  generation  and  delivery  of  a pro- 
duct. The  criteria  for  success  often  depends  on  the  communications  system. 
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error  free  operator  action,  and  other  external  influences  which  are  over  and 
above  the  reliability  requirement  of  the  AFGWC  data  system.  SDC  felt  that  to 
satisfy  the  requirement  reliability,  the  data  system  must  have  a significantly 
higher  reliability  goal. 

For  the  final  system,  SDC  picked  0.995  reliability  as  a design  goal  which  was 
conservative  in  terms  of  satisfying  user  needs,  yet  was  within  the  grasp  of 
AFGWC,  based  on  current  technology  and  cost/risk  design  criteria.  The  ground 
rules  for  the  implementation  period  have  been  to  use  the  present  reliability 
associated  with  AFGWC  as  a lower  limit  while  striving  to  meet  the  new  goal. 

As  individual  requirements  (such  as  WWMCCS)  dictate  the  lower  bound  on  reli- 
ability is  increased  and  new  components  or  architectural  elements  are  imple- 
mented. The  plan  to  implement  Network  Control  in  early  1979  is  a case  involv- 
ing just  such  a reliability  tradeoff.  WWMCCS  will  already  have  been  implemented 
and  Network  Control  would  most  certainly  have  helped  the  system  obtain  the 
necessary  95%  reliability,  but  it  would  have  been  overkill.  By  mid  1978,  all 
major  processors  would  have  been  available  supplying  an  excess  of  power  to 
support  WWMCCS.  Network  Control  does  not  become  a requirement  based  on  reli- 
ability until  the  final  stages  of  the  implementation  schedule. 

Based  on  the  type  of  tradeoffs  just  described  for  Network  Control,  implementa- 
tion of  the  major  subsystems  of  the  AFGWC  enhanced  architecture  have  been 
scheduled  to  occur  in  five  basic  steps  following  the  early  1977  baseline.  The 
time  periods  associated  with  these  steps  are: 

a.  1977  to  early  1978, 

b.  Early  1978, 

c.  Mid  1978, 

d.  Early  1979,  and 

e.  Mid  1979. 

The  following  subsections  discuss  the  baseline  configuration  and  hardware  com- 
ponents to  be  changed  at  each  of  the  ensuing  five  steps. 
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1.1.1  Basel ine 

The  1977  baseline  is  expected  to  consist  of  six  1110  computers.  The  first  will 
handle  SX  functions  with  the  second  processor  acting  as  backup.  The  third 
and  fourth  processors  will  handle  satellite  data  processing  and  non-SX  communi- 
cations, respectively.  The  last  two  processors  will  handle  most  data  updates, 
with  one  machine  running  while  the  second  functions  as  a backup.  The  four 
groupings  (SX,  satellite  processing,  communications,  and  data  base  update)  will 
each  have  a separate  data  base  and  operations  center  associated  with  it.  The 
only  other  major  hardware  subsystem  will  consist  of  the  IPADs  display  system. 
This  whole  system  is  pictured  in  Figure  1.  (The  same  abbreviations  and  symbol 
shapes  will  be  used  consistently  throughout  this  discussion.) 

1.1.2  1977  to  Early  1978 

During  this  period,  the  data  base  processor  will  be  installed.  This  processor 
will  be  necessary  to  handle  the  many  upgrades  and  model  enhancements  expected 
at  this  time.  These  include  atmospheric  and  ionospheric  analysis  and  forecast- 
ing functions  for  different  grids,  resolutions,  and  purposes  (e.g.,  the  advanced 
prediction  model,  ZOOM  and  various  SESS  functions).  The  increased  automatic 
handling  of  new  types  of  satellite  data  during  this  time  period  is  also  expected 
to  require  more  computer  processing  power.  At  this  time.  Special  Projects  com- 
munications will  also  be  upgraded  to  provide  a direct  link  to  the  processors. 
Finally,  a prototype  computer  of  the  3.5  RP  category  will  be  constructed  with 
an  array  processor,  fixed  head  disk,  and  other  components.  Connected  to  this 
prototype  will  be  a data  base,  communications  console,  forecasting  console, 
and  operations  console  so  that  all  facets  of  the  new  system  (both  hardware’and 
software)  can  be  simulated  prior  to  implementation.  Phasing  in  of  programmer 
consoles  will  begin  at  this  point  as  software  development  requirement  dictate 
with  full  implementation  not  completed  till  mid  1979.  The  system  configuration 
at  this  phase  is  pictured  in  Figure  2.  The  following  conventions  will  be  used 
from  this  point  in  such  diagrams: 

^SX  = Special  Projects  Branch,  now  designated  as  WPJ. 
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Figure  1.  Configuration  Baseline  - Early  1977. 
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a.  components  which  will  be  eventually  phased  our  are  cross-hatched, 

b.  components  which  are  being  Installed  as  part  of  a step  being  described 
are  pictured  as  an  outline  containing  an  abbreviation, 

c.  components  which  are  part  of  the  new  configuration  but  are  also  part 
of  a previous  step  are  pictured  as  a blank  outline,  and 

d.  only  the  major  data  flow  lines  involving  components  implemented  in  a 
given  step  are  shown  in  that  step. 

1.1*3  Early  1978 

At  this  time,  the  AFGWC  system  will  be  upgraded  to  handle  the  new  data  base 
concepts  recommended  by  SDC.  This  will  not  only  include  storage  space  but  also 
the  switches  involved  in  data  upgrade  and  control  only  data  lines.  As  the  new 
data  base  concepts  are  implemented,  they  will  remain  invisible  to  the  user  pro- 
grams still  operating  under  former  data  base  procedures;  a transparent  data 
base  interface  will  be  implemented.  Two  new  processor  systems  will  be  imple- 
mented to  handle  the  increased  load  established  by  data  base  management;  new 
operations  consoles  will  also  come  about  at  this  phase.  The  active  implementa- 
tion of  these  two  operations  centers  also  signifies  the  formation  of  the  two 
distinct  operational  perimeters:  special  and  normal  access  (which  is  admittedly 

only  a change  in  semantics  from  the^baseline  system).  The  driving  requirements 
which  will  establish  the  need  for  these  upgrades  include:  increased  Automated 

Weather  Station  input,  WWMCCS,  and  the  ability  to  serve  as  a backup  to  Carswell. 
This  is  pictured  in  Figure  3. 

1.1.4  Mid-1978 

At  this  point,  the  two  remaining  processor  systems  will  be  upgraded  (one  of  them 
originally  the  prototype)  and,  since  this  allows  the  three  access  perimeters  to 
be  established,  major  functions  will  now  be  allocated  to  the  appropriate  pro- 
cessors. Specifically,  PSI  will  be  for  special  access;  PS2  will  be  for  the 
variable  perimeter;  and  PS3,  PS4,  and  PS5  will  make  up  the  normal  access  area. 
This  added  computer  power  will  be  necessary  to  support  Cloud  Free  Line  of  Sight 
programs.  With  the  availability  of  TIROS-N  satellite  data  and  the  inauguration 
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of  the  SID  system,  it  will  be  necessary  to  upgrade  satellite  processing  in 
general,  a function  to  be  assigned  to  PS5.  Finally,  the  communications  upgrade 
started  with  the  prior  implementation  of  PS1  and  PS4  will  continue  as  new  com- 
munications consoles  are  actively  established  for  possible  side-by-side  opera- 
tion of  the  new  and  old  procedures.  See  Figure  4. 

1.1.5  Early  1979 

The  primary  accomplishment  here  will  be  the  implementation  of  Network  Control 
in  its  final  form,  as  shown  in  Figure  5.  Where  switching  the  variable  perimeter 
was  previously  a manual  operation,  it  can  now  be  supervised  by  Network  Control. 
The  predominant  requirement  in  this  time  period  will  be  increased  Minuteman 
support.  (The  reliability  tradeoff  associated  with  the  implementation  of 
Network  Control  is  discussed  in  Section  1.1.) 
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1.1.6  Mid-1979 

By  this  time,  a full  forecaster  console  capability  will  be  implemented,  includ- 
ing forecaster  consoles  in  the  special  access  perimeter  and  several  similar 
types  of  consoles  in  the  normal  access  perimeter,  including  TAF-METWATCH, 
Military  Weather  Advisory,  and  synoptician  consoles.  These  consoles  will  be 
essential  when  the  0-48  hour  Terminal  Air  Forecast  (TAF)  becomes  operational. 
Programmer  support  consoles  in  the  special  access  and  normal  access  perimeters 
(initiated  in  1977  through  early  1978)  will  be  fully  operational  by  this  time. 
Finally  consoles  associated  with  quality  assurance  and  special  operations  will 
be  installed.  This  is  illustrated  in  Figure  6. 

1.2  SOFTWARE  DEVELOPMENT  SCHEDULE  (A32-A34) 

The  availability  of  software  necessary  to  support  hardware  can  be  the  key  fac- 
tor in  meeting  an  implementation  schedule.  This  discussion  has  classified  all 
major  software  projects  bearing  on  the  enhanced  AF6WC  architecture  into  three 
categories: 

a.  model  and  requirement  related, 

b.  enhanced  architecture  related,  and 


c.  vendor  supplied. 
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Figure  6.  Mid-1979  Configuration. 
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Those  involving  models  and  other  requirements  are  independent  of  the  architec- 
ture to  the  extent  that  they  must  be  developed  regardless  of  what  final  hard- 
ware configuration  is  adopted.  Dates  when  they  must  become  operational  are 
based  on  information  collected  in  task  1 of  this  study.  Since  most  of  these 
dates  were  only  identified  by  year,  a mid-point  of  that  year  was  assumed.  Based 
on  the  Air  Force  description  of  these  software  projects  and  on  SDC's  estimates 
of  associated  complexity,  they  were  classified  as  either  involving  high,  moder- 
ate, or  low  amounts  of  design  and  development  efforts.  These  three  classifica- 
tions were  assumed  to  correlate  with  time  periods  of  18,  12,  and  6 months 
respectively. 

The  second  category,  containing  tasks  related  to  the  enhanced  architecture,  are 
those  which  have  resulted  from  SDC's  recommendations.  They  include  the  data 
management  and  Network  Control  Systems,  to  name  two.  These  tasks  were  classi- 
fied as  involving  high,  moderate,  or  low  amounts  of  work  in  the  trade-study 
analysis  and  these  classifications  were  again  assumed  to  correlate  to  18,  12, 
and  6 months,  respectively.  The  dates  when  these  software  tasks  must  be  com- 
pleted is  based  on  the  hardware  implementation  plan  presented  in  Section  1.1. 

:J 
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The  final  category  of  software  development  involves  modification  of  vendor 
supplied  software  to  make  it  suitable  for  use  at  AFGWC.  The  work  involved  in 
each  of  these  tasks  will  most  likely  be  completed  in  less  than  6 months  time 
and  must  be  available  by  the  date  dictated  by  the  hardware  implementation  sched- 
ule in  Section  1.1.  The  resultant  proposed  schedule  is  shown  in  Figure  7. 

1.3  PERSONNEL  SCHEDULE  (A70) 

r| 

The  new  personnel  requirements  for  system  operation  are  integral  to  total  sys- 
tem phaseover/system  architecture  schedule  planning.  This  personnel  schedule 
will  be  considered  in  terms  of  time  periods  consistent  with  the  total  implemen- 
tation plan  of  Section  1.1,  i . e . : 
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MODELS  4 OTHER  REQUIREMENTS 

Tropical  Prediction  Model  based  on 
Spherical  Harmonics 

Primitive  Equation  Window  Model 
Total  Electron  Count  Model 
Ionospheric  Ray  Tracing  Model 
Cloud  Prognoses  Model 
Objective  HWD  Model 
Terminal  Forecast  Model 
Global  Analysis  Model 
Advanced  METSAT  Data  Incorporation  - — 

Incorporation  of  some  VHR  and  WHR 
Satellite  Data  into  3DNEPH 

Advanced  Global  Atmospheric  

Prediction  Model 

Cloud  Free  Line-of-Sight  

Clear  Line-of-Sight 

Statistical  Polar  Ionospheric 
Propagation  Model 

Incorporation  of  most  VHR  and  WHR 
Data  into  3DNEPH 

Extraction  of  Field  of  Motion  

Data  from  GOES 

Improved  TEC  Model 

Improved  F-Region,  Storm  Model 

Clear  Line-of-Sight  for  IR  — 

PE  Window  Model  for  High-Resolution 
Short-Range  forecasts  at  Low  Latitudes 

Variational  Global  Analysis  Model 

Improved  Ionospheric  Magnetospheric  - 
Model 

Incorporation  of  Radiation  Physics  

Module  Into  Global  Prediction  Model 

Neutral  Density  Model  

Processing  of  DMSP,  TIROS 
Primary  Data 

Processing  of  GOES  Primary  Data 
Processing  of  TIRDS  Secondary  Data 
Processing  of  GOES  Secondary  Data 
Product  Request  Processing 
ETAC,  Carswell  Backup 
SID 

0 - 4B  hour  TAF 

ENHANCED  ARCHITECTURE  SOFTWARE 
Communications  Support 
Data  Management  System 
Meteorological  Data  8a$e 

Data  Management  System 
Transparency 

Network  Control  for 
Dedicated  Systems 

Network  Control  for 
Centralized  Operation 

Programmer  Support 
Forecaster  Support 

Interface  and  Support 
Processors 

VENDOR  SUPPLIED 
Data  Driented  Language 
Compilers 
Maintenance 
Programmer  Interface 
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Figure  7 


Software  Development  Schedule 
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a.  1977  - early  1978, 

b.  early  1978, 

c.  mid-1978, 

d.  early  1979,  and, 


e.  mid-1979. 

Personnel  requirements  associated  with  model  software  development  are  covered 
in  Section  2.1  of  Volume  2.  Requirements  for  the  production  of  other  major  pro- 
grams should  be  based  on  the  estimated  sizings  and  projected  characteristics  of 
these  routines  as  described  under  Trade  Study  ACI-I  in  Section  10.0  of 
Volume  4. 


1.3.1  System  Requirements 

The  personnel  schedule  considers  the  primary  system  requirements  with  respect 
to  accommodation  for  data  system  growth,  limitations  to  increases  in  personnel, 
and  training  requirements.  Specific  considerations  are  as  follows: 

a.  The  1982  design  shall  accommodate  a 10%  growth  in  number  of  devices 
and  a 10%  growth  in  traffic  per  work  center  between  1982  and  1987. 


Data  system  potential  growth  within  the  1982  - 1987  time  period  shall 
require  no  increase  in  personnel. 

Operator  positions  shall  accommodate  on-the-job  training. 

The  number  of  consoles  reflected  in  the  AFGWC  Data  System  Architecture 
and  the  number  of  personnel  allocated  to  console  positions  (as  deter- 
mined from  the  System/Design  Trade  Study  Report)  are  the  basis  for 
determining  the  personnel  schedule  during  system  implementation. 

The  prototype  system  planned  for  implementation  in  1977  - early  1978 
will  be  operated  and  maintained  by  contractor  personnel;  therefore, 
AFGWC  operational  personnel  are  involved  only  for  training  (within  the 
context  of  on-the-job  training)  as  needed  for  implementation  of  system 
phaseover. 
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1.3.2  Personnel  Requirements  for  System  Operation 


a.  1977  - early  1978.  During  this  period,  the  AF6WC  will  implement  the 
data  base  system,  plus  several  prototype  subsystems  connected  to  a 
prototype  processing  system.  This  period  involves  the  addition  of 
one  (1)  maintenance  console  to  support  the  database  processor.  Based 
upon  console  personnel  allocations  developed  during  the  system/design 
trade  study  activity,  personnel  requirements  for  this  phase  of  imple- 
mentation are  two  slots  allocated  for  this  maintenance  console.  In 
addition,  initial  manning  of  the  programmer  consoles  will  commence 
for  software  development.  Employing  the  assumptions  that  programmer 
consoles  will  be  manned  2/3  of  the  time,  and  that  these  consoles  should 
be  utilized  as  soon  as  is  practical,  it  is  estimated  that  10  slots 
will  be  devoted  to  programmer  console  usage  during  this  period. 

b.  Early  1978.  In  the  early  1978  period,  the  processing  system  in  the 
Special  Access  Perimeter  and  a processing  system  in  the  Normal  Access 
Perimeter  will  be  implemented.  Four  data  base  subsystems  and  the  data 
transfer  and  routing  components  will  also  be  implemented.  In  addition, 
the  Operations  Subsystems  for  both  perimeters  (Special  Access  and 
Normal  Access)  will  be  implemented.  This  will  result  in  the  following 
additional  console  requirements: 

1)  two  (2)  computer  operations  consoles, 

2)  two  (2)  security  downgrade  and  remote  job  entry  consoles, 

3)  two  (2)  maintenance  consoles. 

This  phase  of  the  implementation  requires  personnel  as  follows: 

1)  Twenty  (20)  slots  are  required  for  the  computer  operations  con- 
soles. This  is  based  upon  a requirement  for  two  slots  per  shift, 
and  assumes  five  shifts  per  day  for  7-day,  24-hour  operations, 
for  each  of  the  two  consol es* 
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2)  Ten  (10)  slots  are  required  for  the  security  downgrade  and  remote 
job  entry  (SD/RJE)  consoles  (one  slot  per  shift  for  each  console). 

3)  Four  (4)  new  slots  are  required  for  the  two  new  maintenance 
consoles. 

In  addition,  10  additional  programmer  slots  will  be  allocated  to 
software  development  on  the  programmer  consoles. 

c.  Mid-1978.  In  mid-1978,  the  final  two  processing  systems  will  be 

implemented,  one  in  the  Variable  Access  Perimeter  and  the  other  in  the 
Normal  Access  Perimeter.  Included  also  are  those  upgrades/subsystem 
implementations  associated  with  satellite  data  input  and  Satellite 
Imagery  Dissemination  (SID)  and  the  active  implementation  of  the 
communication  systems  in  both  the  Special  Access  Perimeter  and  the 
Normal  Access  Perimeter.  This  implementation  period  involves  the 
addition  of: 

1)  two  (2)  communications  consoles, 

2)  two  (2)  maintenance  consoles,  and, 

3)  one  (1)  SID  console. 

Personnel  requirements  for  this  period  involve  twenty  (20)  slots  for 
the  communication  consoles,  four  (4)  new  slots  for  the  maintenance 
consoles,  and  ten  (10)  slots  for  the  SID  console.  As  before,  the 
personnel  requirements  for  the  maintenance  consoles  are  based  on  the 
total  of  ten  slots  for  the  five  maintenance  consoles.  The  ten  slots 
for  the  SID  console  reflect  a requirement  for  two  slots  per  shift, 
while  each  coirmuni cations  console  may  require  as  many  as  two  operators 
per  shift. 

d.  Early  1979.  The  projected  schedule  for  Network  Control  console  imple- 
mentation occurs  in  early  1979,  An  additional  two  (2)  consoles  are 
involved  in  this  phase  of  implementation.  However,  only  one  will  be 
manned  - the  other  will  be  in  standby  status.  Based  upon  use  of  two 


16 


slots  per  shift,  the  personnel  requirement  reflects  a total  of 
ten  (10)  slots. 

Mid-1979.  The  implementation  shcedule  provides  for  implementation  of 
the  forecaster  and  quality  assurance  consoles  by  mid-1979.  The  imple- 
mentation is  as  follows: 

1)  Fifteen  (15)  for  TAF/METWATCH 

2)  Two  (2)  for  SESS  (one  each  in  Special  Access  and  Normal  Access 
Perimeters) 

3)  One  (1)  for  Military  Weather  Advisories 

4)  Five  (5)  synoptician  consoles 

5)  Three  (3)  forecaster  consoles  in  Special  Access  Perimeter 

6)  One  (1)  special  operations  console 

7)  One  (1)  quality  assurance  console 

Based  upon  the  number  of  slots  per  shift  for  each  console,  the  follow- 
ing personnel  requirements  for  this  phase  of  implementation  are  as 


follows: 

1)  TAF/METWATCH 150 

2)  SESS 15 

3)  Military  Weather  Advisories  10 

4)  synoptician  consoles 50 

5)  Special  Access  Perimeter 

forecaster  consoles  15 

6)  special  operations  console 10 

7)  quality  assurance  console  5 
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1.3.3  Summary  of  Personnel  Requirements 

Table  1 presents  the  Production  Division  personnel  requirements  in  terms  of  the 
number  of  slots  required  for  console  manning  for  each  phase  of  the  system  imple- 
mentation from  1977  through  mid-1979.  The  total  involved  in  console/work 
center  operation  by  mid  1979  is  355. 


Based  upon  the  estimates  of  total  AFGWC  manpower  requirements  through  1982,  as 
indicated  initially  in  the  task  1 Preliminary  Report,  the  impact  of  this  sched- 
ule on  total  WP  manning  can  be  reviewed.  The  estimated  total  manpower  in 
Figure  8 reflects  personnel  requirements  to  meet  new  user  requirements,  aug- 
mented by  the  manpower  savings  due  to  automation,  from  1977  to  1982,  with  the 
maximum  number  of  WP  personnel  estimated  as  755  in  1980  and  beyond.  Super- 
imposed on  the  graph  of  total  manpower  is  the  portrayal  of  the  number  of  per- 
sonnel required  for  console  and  automated  work  center  operation  of  the  AFGWC 
data  system.  The  stepwise  growth  in  the  number  of  personnel  required  shows 
increases  from  twelve  in  1977  - early  1978  to  a maximum  of  355  in  mid-1979. 

Figure  9 shows  the  portion  of  the  total  AFGWC  manpower  required  for  operation 
of  the  data  system  consoles  and  work  centers  in  terms  of  the  percentage  of  the 
total  requirements  (assuming  a WP  staffing  level  of  755  in  1980).  The  step- 
wise growth  to  mid-1979  shows  increases  from  1.6  percent  to  13  percent  of  the 
total  manpower.  The  increase  to  47%  of  total  manpower  in  mid-1979  mainly 
represents  the  requirements  for  implementation  of  the  forecaster  consoles  in 
both  the  Normal  Access  Perimeter  and  the  Special  Access  Perimeter. 


^Tables  8 and  9 are  based  on  an  assumed  total  authorized  staffing  for  the  AF 
GWC  Production  Division  of  720  in  1976.  However,  it  should  be  noted  that  this 
division  is  operating  at  well  below  authorized  levels.  In  late  1975,  for 
example,  the  six  major  operating  branches  of  WP  (WPF,WPD,WPE,WPP,WPJ,WPA)  had 
549  assigned  personnel. 
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System  Console  Operation 


Figure  8.  AF6WC  Personnel  Schedule 
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1.4  FACILITIES  (A90) 


One  of  the  ground  rules  used  in  the  design  of  the  AFGWC  system  has  been  to  use 
existing  facility  space  and  supporting  environment  when  possible.  As  a result, 
the  architecture  that  has  been  designed  is  by  nature  compatible  with  the  exist- 
ing facility  resources.  The  following  sections,  however,  will  summarize  some 
of  the  situations  to  which  the  facilities  must  react. 


AFGWC  room  numbers  referred  to  in  the  following  discussion  are  as  described  by 
Figures  10  and  11,  which  picture  all  facility  space  at  AFGWC.  The  time  periods 
over  which  this  discussion  is  organized  again  follow  those  established  by  the 
implementation  plan  in  Section  1.1. 


a*  19.77  to  Early  1978.  Implementation  of  the  data  base  processor  will 
most  likely  use  facility  space  available  in  the  lower  level  in  Room 
L30,  as  adequate  space  should  be  available  there.  The  prototype 
should  ideally  be  housed  within  AFGWC  facilities  but  it  is  doubtful 
that  there  will  be  enough  room.  The  alternative  to  this  temporary 
setup  will  most  likely  have  to  be  a vendor  supplied  depot  at  a loca- 
tion easily  accessible  to  AFGWC  personnel.  The  upgraded  special  access 
communications  link  provides  no  special  impact  on  facilities. 

Programmer  consoles  are  being  placed  in  locations  outside  of  the 
larger  hardware  areas  housing  the  processor  systems,  in  areas 
already  in  use  as  normal  work  areas  by  programmers. 


b. 


. 


Early  1978.  The  establishment  of  centralized  operations  consoles  will 
require  some  construction  to  make  them  suitable  working  areas.  This 
will  occur  in  Rooms  17  and  43  on  the  main  floor.  Since  the  new  data 
base  and  processor  are  replacing  existing  components,  supplying  room 
for  them  should  be  no  problem.  The  upgrade  and  control  only  data 
switches  should  not  take  up  much  more  room  and  there  should  be  ample 
room  available  in  the  new  location.  Room  43.  This  period  will  see  the 
establishment  of  the  perimeter  between  normal  and  special  access  but 
this  should  coincide  with  the  present  adequate  boundary  between 
Rooms  38  and  43. 
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Figure  11.  AFGWC  Main  Floor  Facility 
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c.  Mid-1978.  The  implementation  of  the  final  two  processors  will  allow 
the  three  distinct  perimeters  to  be  established.  This  will  require 
necessary  security  reinforcements  betwen  Rooms  17  and  38,  the  boundary 
between  the  normal  and  variable  perimeters.  Facilities  for  the  new 
communications  hardware  and  consoles  should  be  adequate  in  Rooms 

43  and  L30t 

d.  Early  1979.  The  implementation  of  the  network  control  console  in 
Room  43  will  require  construction  to  isuiUte  this  working  area  from 
the  noise  in  the  remainder  of  the  special  access  area. 

e.  Mid-1979.  Forecaster  consoles  are  being  placed  in  locations  outside 
of  the  larger  hardware  areas  housing  the  processor  system.  Some 
minor  re-organization  may  be  necessary  to  ensure  their  proper  place- 
ment, since  they  will  be  established  in  areas  already  in  use  as 
normal  work  areas  by  forecasters. 

1.5  NETWORK  SCHEDULING  ASPECTS 

SDC  has  assessed  many  of  the  time-dependent  implications  and  interdependencies 
of  components  of  the  architectural  domain,  and  has  prepared  associated  data  for 
input  to  automated  network  scheduling  programs.  Activities  associated  with  the 
implementation  of  hardware  and  software,  as  well  as  personnel  training  and  fa- 
cility modification  tasks,  are  presented  in  Tables  2-5.  In  each  of  these  tables, 
SDC  has  established  nominal  durations  for  activities,  as  well  as  nominal  start 
and  end  dates  (with  estimated  tolerances).  Included  also  are  required  pre- 
decessor activities.  All  of  these  efforts  are  based  on  the  presentations  de- 
veloped in  Sections  1.1  - 1.4,  and  will  be  instrumental  in  establishing  a 
complete  scheduling  network  with  all  interdependencies,  so  that  critical  paths, 
variances,  and  allowable  slack  times  may  be  assessed  and  optimized. 
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Not  part  of  new  data  systen  architecture. 
Including  programmer  work  centers. 

AFGVJC  "Data  Base  Processor 
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Table  3.  Software  Development  & Implementation  Schedule 
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Ml"  indicates  model  no.  1 - see  Section  2.0  of  Volume 
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Table  3.  Software  Development  & Implementation  Schedule  (Continued) 
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Duration"  for  oersonnel  refers  to  phase-in/training  period. 


Table  5.  Facilities  Implementation  Schedule 


2.0  SYSTEM  COST  CONSIDERATIONS 

2.1  SYSTEM  COST  SUMMARY 

Table  6 summarizes  time-phased  system  costs  from  1977  through  1981,  which  are 
detailed  in  Sections  2.3  through  2.6.  All  costs  are  based  on  1975  dollars,  re- 
flecting current  prices  for  analogous  components  and  SDC's  best  estimates  for 
new  state-of-the-art  equipment. 

It  should  be  noted  that  many  factors  will  influence  the  actual  dollars  that 
must  be  incrementally  appropriated  to  procure  this  data  system.  In  most 
sectors  of  the  economy,  inflation  is  resulting  in  increased  prices  for  goods 
and  services,  and  will  most  probably  continue  to  do  so  for  the  foreseeable 
future.  The  general  rate  of  inflation,  however,  does  not  entirely  apply  to 
the  data  processing  industry.  While  costs  for  software  services  are  continu- 
ing to  rise  {due  largely  to  increases  in  programmer  salaries),  several  avenues 
of  the  hardware  acquisition  and  maintenance  worlds  are  experiencing  price  re- 
ductions for  given  capabilities.  Such  reductions  are  partly  due  to  dramatic 
decreases  in  main  memory  costs,  higher  reliabilities,  and  lower  production 
costs  associated  with  LSI  and  CMOS  technologies.  In  fact,  it  is  conceivable 
that  as  more  advanced  technologies  emerge,  lower  prices  than  those  shown  here- 
in could  result  in  the  long  term. 

Unfortunately,  in  meeting  AFGWC  needs  in  the  1977-1982  time  frame,  much  of 
the  associated  R&D  costs  of  the  vendors  have  already  been  expended.  Since 
the  emphasis  on  the  acquisition  of  new  architecture  components  to  meet  user 
requirements  will  be  in  the  1977-1979  period,  hardware  component  costs  cannot 
realistically  be  expected  to  drastically  go  down  during  this  relatively  short- 
term period.  Software  costs,  however,  will  most  certainly  continue  to  in- 
increase in  proportion  to  inflation  rates.  Thus,  for  the  acquisition  of  the 
new  AFGWC  data  system,  system  acquisition  over  the  1977-79  period  can  be 
expected  to  be  higher  than  these  1975  prices,  but  possibly  not  in  direct 


Table  6.  Time  Phased  System  Costs  (Numbers  in  Millions  of  Dollars)  Through  1981 


proportion  to  inflation.  In  the  final  analysis,  however,  decisions  must  be 
made  regarding  the  adequate  meeting  of  user  requirements  and  the  appropriate 
allocation  of  funds  to  meet  these  requirements. 


2.2  TIME  PHASED  COST  SUMMARY 

Tables  7 through  11  detail  estimated  time  phased  costs  of  hardware  components 
for  the  AFGWC  system.  These  tables  coincide  with  the  five  periods  associated 
with  the  implementation  schedule  presented  in  Section  1.1.  Software  develop- 
ment and  conversion  costs  are  also  listed  in  these  summaries.  Symbols  and 
abbreviations  for  hardware  components  are  those  appearing  on  the  system  dia- 
gram foldout  enclosed  with  Volume  1,  "Executive  Summary." 

I 

2.3  SYSTEM  ARCHITECTURE  COSTS  (A10-A60) 

1 

Tables  12  through  17  summarize  the  total  costs  associated  with  the  AFGWC  sys- 
tem architecture,  organized  to  follow  the  first  six  divisions  (the  hardware 
components)  of  the  architectural  domain: 

a.  data  storage  (A10) 

b.  data  transfer  and  routing  (A20) 

c.  computation  and  software  (A30) 

d.  terminal  interface  (A40) 

e.  consoles  (A50) 

f.  data  input/display  (A60) 

Personnel  (A70)  and  Facilities  (A90)  are  covered  below.  The  management 
division  (A80)  is  assumed  to  have  no  direct  bearing  on  costs.  A total  cost 
summary  for  hardware  and  software  components  appears  in  Table  18. 


2.4  PERSONNEL  (A70) 

Using  the  estimates  of  manpower  established  in  Section  1.3  and  assuming  an 
average  cost  of  $30,000  per  man  year,  Figure  12  depicts  the  Increases  in  yearly 
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AFGWC  personnel  requirements  to  support  new  requirements  and  operate  the  new 
data  system  configuration,  partially  offset  by  manpower  savings  that  would 
arise  through  the  use  of  automated  techniques  (see  Section  5.6  of  Volume  2 for 
details). 

It  should  be  noted  that  $30,000  per  Air  Force  man  year  is  merely  a gross 
estimate  of  the  government's  cost  to  provide  a man  to  perform  these  functions. 
Capabilities  may  range  from  those  of  a medium  grade  enlisted  man  to  a senior 
level  officer,  depending  on  the  function.  Thus,  assuming  that  the  government1 
cost  would  be  well  below  that  of  a vendor,  an  overall  figure  of  $30,000  has 
been  assumed.  However,  it  should  also  be  noted  that  personnel  costs,  while 
included  herein  to  provide  an  overall  picture  of  costs  associated  with  the 
data  system,  will  not  be  part  of  the  same  budget  used  to  acquire  hardware  and 
vendor-supplied  software  for  the  data  system. 


Table  7.  1977  - Early  1978  Costs 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION 

COMPONENTS 

QUANTITY 

53u 

■ 

Processing  System 

MP/IO,  MPS'jiI 

1 

1206K 

1206K 

(Normal  Access 

MEM  (MP) 

1 

3511 

3511 

Perimeter) 

MEM  (MP)  - AUX 

1 

2304 

2304 

AP 

1 

500 

500 

K 

2 

5 

10 

CONT  (FH) 

2 

104 

208 

FH  DISKS 

4 

79 

316 

MAI NT.  CONSOLE 

1 

72* 

72* 

Programmer 

SW 

2 

10 

20 

Subsystem 

ACRT 

30 

4 

120 

ANK 

30 

2 

60 

PLOTTER 

4 

15 

60 

Prototype  Processing 

(Same  as  processing 

1 

8127 

8127 

System 

system  above) 
PR 

1 

56 

56 

Communications 

SP 

1 

300 

300 

Systerti 

LHDR 

2 

20 

40 

Simulation 

LCSD 

2 

8 

16 

COMM  CONSOLE 

1 

5 

5 

ACRT 

2 

4 

8 

ANK 

1 

2 

2 

Forecaster 

SP 

1 

300 

300 

Console  Prototype 

CONSOLE 

1 

13 

13 

HCRT 

2 

50 

100 

CCRT 

2 

5 

10 

ANK 

2 

2 

4 

FFK 

1 

2 

2 

DT 

2 

5 

10 

HC 

1 

5 

5 

LP 

1 

1 

1 

*Cost  based  on:  1 - LPR  @ 56K  and  1 - CRDR  @ 16K 
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SYSTEM/SUBSYSTEM 

IMPLEMENTATION 

COMPONENTS 

QUANTITY 

UNIT 

COST 

TOTAL 

COST 

Prototype  Data 

COMB  DISKS 

4 

39 

156 

Base 

CONT(C) 

2 

68 

136 

BULK  DISKS 

8 

39 

312 

CONT(B) 

2 

102 

204 

MSF 

1 

676 

678 

TAPE  UNITS 

2 

26 

52 

CONT(T) 

2 

78 

1 56 

Software  Development  and  Conversion 

- 

- 

8100K 

TOTAL 

27180 

Table  8.  Early  1978  Costs 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION 

COMPONENTS 

QUANTITY 

UNIT 

COST 

TOTAL 

COST 

Processing  System 

(See  components  listed 

1 

8127K 

8127K 

(Special  Access 

in  chart  for  1977  - 

Perimeter) 

Early  1978.) 

Processing  System 

(See  components  listed 

1 

8127K 

8127K 

(Normal  Access 

in  chart  for  1977  - 

Perimeter) 

Early  1978.) 

Data  Base  Sub- 

SW1  and  SW8 

2 

10 

20 

system  (Special 

CONT  (C) 

6 

68 

408 

Access  Perimeter) 

CONT  (T) 

3 

78 

234 

TAPES 

6 

26 

156 

COMB  DISKS 

24 

39 

936 

Data  Base  Sub- 

SW4  and  SW19 

2 

10 

20 

system  (Normal 

CONT  (C) 

6 

68 

408 

Access  Perimeter)* 

CONT  (T) 

2 

78 

156 

TAPES 

6 

26 

156 

COMB  DISKS 

21 

39 

819 

SW7  and  SW8 

2 

10 

20 

CONT  (B) 

1 

102 

102 

CONT  (C) 

3 

68 

204 

BULK  DISKS 

10 

39 

390 

COMB  DISKS 

16 

39 

624 

DBSW 

1 

10 

10 

SW5  and  SW6 

2 

10 

10 

CONT  (SAT) 

2 

165 

330 

SAT  DISKS 

13 

60 

780 

Data  Transfer  and 

UP  ROUTER 

1 

15 

15 

Routing  Components 

CO  ROUTER 

1 

T5 

T5 

Ops  Subsystem 

SP 

4 

300 

1200 

(Special  Access 

SW 

3 

10 

30 

Perimeter) 

OPS  CONSOLE 

1 

5 

5 

SD/RJE  CONSOLE 

1 

5 

5 

ACRT 

3 

4 

12 

ANK 

3 

2 

6 

•ff 

To  be  augmented  by  Prototype  equipment 

Table  8.  Early  1978  Costs  (Continued) 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION 


COMPONENTS 


QUANTITY 


LCSD  (FDU) 

1 

8 

8 

CONT  (S) 

3 

18 

54 

SUP  DISKS 

3 

7 

21 

Ops  Subsystem 

SP 

5 

300 

1500 

(Normal  Access 

SW 

3 

10 

30 

Perimeter)* 

OPS  CONSOLE 

1 

5 

5 

SD/RJE  CONSOLE 

1 

5 

5 

K 

4 

5 

20 

ACRT 

3 

4 

12 

ANK 

3 

2 

6 

PR 

3 

56 

168 

SPR 

2 

310 

620 

LCSD  (FDU) 

1 

8 

8 

CONT  (S) 

3 

18 

54 

SUP  DISKS 

3 

7 

21 

Software  Development  and  Conversion: 

To  be  augmented  by  prototype  equipment 

- 

TOTAL 

382  5 K 
29682 

■ 


*mmrnrm»  _ 


Table  9.  Mid-1978  Costs 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION 

COMPONENTS 

QUANTITY 

UNIT 

COST 

TOTAL 

COST 

Processing  System 

(already  costed 

(Variable  Access 

as  prototype 

Perimeter) 

processor) 

Processing  System 

(See  components 

1 

8127K 

8127K 

(Normal  Access 

listed  in 

Perimeter) 

chart  for 

1977  - Early 

1978.) 

SID  Subsystem 

CONT  (S) 

1 

18 

18 

SUP  DISK 

1 

7 

7 

SID  CONSOLE 

1 

5 

5 

ACRT 

1 

4 

4 

HCRT 

1 

50 

50 

ANK 

1 

2 

2 

Communications 

LHDR 

3 

20 

60 

System  (Special 

SW 

2 

10 

20 

Access  Perimeter) 

LCSD 

2 

8 

16 

COMM  CONSOLE 

1 

5 

5 

ACRT 

1 

4 

4 

ANK 

1 

2 

2 

Communications 

LHDR 

3 

20 

60 

System  (Normal 

SW 

2 

10 

20 

Access  Perimeter)* 

Software  Development  and  Conversion: 

11251 

TOTAL  9525 

i 

i 


* 


to  be  augmented  by  prototype  equipment 


Table  10.  Early  1979  Costs 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION  COMPONENTS 


QUANTITY 


Network  Control 
Subsystem 


NCSW  l 
NETWORK  CONTROL  CONSOLE  2 
NETWORK  SWITCH  PANEL  1 


Software  Development  and  Conversion: 


Table  11.  Mid-1979  Costs 


SYSTEM/SUBSYSTEM 

IMPLEMENTATION 

COMPONENTS 

QUANTITY 

Forecaster  Con- 

CONSOLES 

sole  Subsystem* 

TAF/MET 

15 

SESS 

2 

MWA 

1 

SYNOP 

4 

SA  FORECASTER 

3 

ACRT 

36 

HCRT 

48 

ANK 

46 

CCRT 

10 

FFK 

10 

HC 

24 

DT 

12 

LP 

24 

CONT  (2) 

1 

SUP  DISK 

4 

SP 

3 

STSW 

1 

Quality  Assurance 

CONSOLE 

1 

Work  Center 

ACRT 

1 

HC 

1 

LP 

1 

Special  Operations 

CONSOLE 

1 

Work  Center 

ACRT 

2 

ANK 

2 

CARD  RDR 

1 

195K 

26 

13 

52 

39 

144 

2400 

92 

50 

20 

120 

60 

24 

18 

28 

900 

10 


Software  Development  and  Conversion 


to  be  augmented  by  prototype  equipment 


TOTAL  5159 


Table  12.  Data  Storage  Costs  (A10) 
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Included  with  processor  costs 
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Table  16.  Console  Costs  (A50) 
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Table  17.  Data  Input/Display  Costs  (A60) 
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Table  18.  Data  System  Architecture  Cost  Summary 


Figure  12.  Increased  Annual  Personnel  Cost  Summary 


2.5  FACILITIES  (A90) 

The  costs  involved  with  facility  modifications  outlined  in  Section  1.4  are 
minor.  While  some  small  costs  will  exist  for  new  security  arrangement,  re- 
cabling, partition  reconfiguration,  etc.,  these  costs  are  expected  to  be  quite 
low  compared  to  the  acquisition  costs  of  the  data  system  itself. 

2.6  MAINTENANCE  AND  SUPPORT 

Calculation  of  maintenance  costs  must  be  based  on  a number  of  considerations 
and  assumptions.  SDC  has  approached  each  major  hardware  component  and 
assessed  the  special  circumstances  surrounding  maintenance  which  applies  to 
these  components. 

First  of  all,  consoles  are  not  a sufficiently  costly  item  (and  they  are  not 
sufficient  in  quantity)  that  we  will  find  vendors  willing  to  supply  on-site 
maintenance.  Furthermore,  it  is  unlikely  that  a vendor  of  consoles  would  be 
located  in  Omaha.  Hence,  it  will  be  necessary  to  train  military  personnel  to 
isolate  faults  to  the  plug-replaceable  unit  level  and  to  replace  items  within 
the  consoles.  Accordinly,  a spare  parts  inventory  for  consoles  must  be  kept. 

Most  likely  each  of  the  three  different  kinds,  programmer,  operations  and 
forecaster  consoles  would  have  different  spare  parts  inventories.  These  spare 
parts  must  be  kept  in  an  environmentally  controlled  area  to  maintain  their 
longevity.  If  array  processors  are  not  procured  from  the  same  manufacturers 
as  the  hosts,  it  may  be  necessary  that  military  personnel  also  be  able  to  re- 
place pluggable  units  on  the  array  processors  after  having  isolated  faults  via 
vendor  supplied  diagnostics.  In  this  case,  again,  there  will  have  to  be  a 
spare  parts  inventory  kept.  The  cost  of  spare  parts  should  be  estimated  at 
about  10%  of  the  cost  of  the  unit  itself  in  terms  of  a spare  parts  inventory 
and  this  should  be  proportional  to  the  number  of  units.  The  amount  of  time  it 
will  take  to  exhaust  the  spare  parts  purchased  by  this  10%  factor  will  vary 
with  the  components.  In  Table  19,  maintenance  costs  are  estimated  for  various 
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Table  19.  Life-Cycle  Maintenance  Costs 


TOTAL 
10-YEAR 
LIFE  CYCLE 
COST 


Mass  Storage 
Facility  Media 

$ . 1 75K 

1 

Switches 

$24K 

10 

Authentication 

Chips 

$38K 

5 

Array 

Processors 

$250K 

5 

Forecaster 

Consoles 

$300K 

2 

Operations 

Consoles 

$4K 

2 

II.  VENDOR  SUPPLIED  MAINTENANCE 
(PARTS  INCLUDED) 

SYSTEM 

COMPONENT 

ANNUAL 

COST 

Main  Processors 

$1 .75M 

Support  Processors 

$250K 

Disks 

$350K 

Programmer  Consoles 

$1  OK 

I.  MAINTENANCE  BASED  ON  PARTS  COST 


SYSTEM 

COMPONENT 


SPARE  PARTS 
COST  (10%  OF 
PURCHASE  COST) 


YEARS  TO 
EXHAUST 
SPARE  PARTS 


III. 


ANNUAL  AF6WC  TRAINING  - $b 


f 

V[ 


I 


!' 

j 

i 


system  components  over  an  expected  10-year  life  cycle.  These  costs  are 
"average"  since  they  are  based  on  the  expected  system  configuration  in  1982, 
the  mid-point  of  the  10-year  period. 

Although  hardware  maintenance  is  definitely  the  largest  recurring  system  cost, 
there  are  others  which  must  be  considered: 

a.  software  maintenance, 

b.  power  and  environmental  support,  and 

c.  supplies  and  consummables. 

Based  on  previous  software  experience,  SDC  believes  that  a maximum  of  5%  of 
software  personnel  need  be  dedicated  to  the  function  of  software  maintenance. 
(Software  maintenance  as  used  here  consists  of  error  corrections  and  minor 
engineering  changes.  It  only  involves  clean-up  of  existing  code  and  design 
and  not  program  development).  This  estimate  may  seem  low  based  on  AFGWC 
experience  since  the  software  development  branch,  WPA,  is  much  smaller  than 
the  sections  in  WPD  dedicated  to  program  maintenance.  The  conflict  lies  in 
the  fact  that  much  of  the  work  done  by  WPD  maintenance  programmers  consists  of 
much  more  than  error  correction  and  cleanup.  SDC  further  feels  that  the  5% 
figure  will  decrease  after  late  1978  when  the  large  influx  of  new  models  slows 
down  and  those  in  production  become  more  stable. 

Power  and  environmental  support  (air-space  conditioning,  water,  etc.)  will  re- 
main a comparatively  minor  recurring  cost  at  AFGWC.  It  is  estimated  that  this 
aggregate  cost  will  be  much  less  than  the  cutoff  of  1%  of  system  cost.  Amounts 
significantly  below  this  limit  have  been  ignored  in  this  analysis. 


I 


Supplies  and  consummables  include: 

a.  Punched  cards, 

b.  Magnetic  tapes. 


k 
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c.  Paper  for  printers, 

d.  Paper  for  CRT  hard/copy  devices, 

e.  Paper  for  facsimile  display. 

These  materials  are  estimated  to  have  an  annual  cost  of  $750,000.  Being 
ignored  is  film  for  satellite  display  processing.  Film  usage  should  be 
greatly  reduced  with  the  advent  of  forecaster  consoles.  Moreover,  film  usage 
has  been  associated  with  Site  3 satellite  data  communications— this  area  has, 
for  the  most  part,  been  outside  the  scope  of  SDC*s  analyses. 

In  summary,  annual  maintenance  of  the  system  should  run  at  aporoximately 
$3.35  million  dollars,  including  hardware,  supplies  and  consummables. 


3.0  RISK  ANALYSIS 


"Risk"  can  be  defined  as  the  expected  impact  of  failure,  or  equivalently,  the 
probability  of  failure  multiplied  by  the  quantified  result  (such  as  dollar  cost) 
of  failure.  Under  this  definition,  risk  can  be  separated  into  the  following 
categories: 

a.  Performance 

b.  Cost 

c.  Schedule 

d.  Mission  Suitability 

e.  Scope 

These  five  topics  are  discussed  individually  in  the  sections  that  follow.  The 
discussions  are  mostly  subjective  rather  than  quantitative,  and  deal  with  the 
means  by  which  risk  was  minimized.  Architectural  features  which  are  of  higher 
than  average  risk  are  identified. 

3.1  PERFORMANCE 

Failure  of  a system  to  perform  adequately  can  be  the  result  of  either  inade- 
quate estimates  or  faulty  design  (changing  requirements  are  dealt  with  under 
3.4,  "Mission  Suitability").  In  the  paragraphs  that  follow,  inadequate  estima- 
tion is  dealt  with  first,  followed  by  design  characteristics.  The  design 
characteristics  are  further  broken  down  into  throughput,  storage  capacity, 
reliability,  operation,  and  security. 

3.1.1  Estimation  of  Requirements 

The  risk  of  erroneous  estimates  was  minimized  at  several  stages  during  the 
study.  During  task  1,  several  requirements  were  "white-papered"  and  excluded 
from  further  consideration  because  they  were  ill-posed  problems  or  were  without 
serious  foundation.  These  were  coordinated  with  the  Air  Force.  In  addition, 
the  translation  of  the  impact  of  operational  requirements  into  data  processing 
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requirements  was  a joint  effort  by  SDC  and  cognizant  AF6WC  personnel.  The 
measurement  space  used  was  familiar  to  AFGWC  personnel;  for  example,  CPU  time 
was  measured  in  terms  of  1108  CPU  time.  SDC  then  converted  this  measurement 
space  to  other  computers  using  conservative  relative  throughput  values.  This 
conversion  was  done  using  industry  accepted  values. 


SDC  then  performed  an  analysis  of  the  12-hour  AFGWC  production  cycle,  termed 
a "Network  Analysis"  for  the  network  of  predecessor-successor  relationships. 
This  Network  Analysis  was  performed  for  both  the  peak  and  the  average  cases. 
The  peak  case  was  used  to  design  the  hardware  resources  required.  This  peak 
is  significantly  higher  than  the  average,  and  thus  a safety  factor  has  been 
built  into  the  architecture  for  peak  loads,  which  also  guards  against  mis- 
estimation  of  requirements. 
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In  the  process  of  compiling  requirements,  it  became  clear  that  the  character 
of  the  data  system  must  change  considerably  with  respect  to  security  in  the 
next  four  years.  Externally  induced  and  unpredictable  workloads  would  be 
imposed  on  the  system  due  to  Query/Response  support  of  Command  and  Control 
Systems.  This  workload  would  have  a variable  mixture  of  security  levels. 
Furthermore,  the  requirement  was  of  highest  priority  yet  still  at  the 
conceptual  level,  making  definition  of  characteristics  difficult.  To  account 
for  the  large  error  ellipsoid  in  these  requirements,  SDC  designed  a data 
system  in  which  processors  can  "float"  between  security  levels  under  a 
central  Network  Control.  With  knowledge  of  AFGWC  resources  and  loading  that 
spans  the  data  system,  the  Network  Control  can  shift  resources  to  meet  varying 
demands.  Without  this  concept,  processors  must  be  dedicated  to  security  levels 
and  to  functions,  providing  only  fixed  resources  that  must  be  predetermined. 
With  global  Network  Control  capability  and  "floating"  processors,  AFGWC  can 
react  to  crisis  or  wartime  conditions  that  have  unpredictable  loads  at  each 
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3.1.2  Design  Characteristics 

Given  a proper  interpretation  of  requirements,  there  still  remains  the  risk 
that  the  architecture  may  not  function  properly.  This  risk  was  minimized  by 
SDC  through  the  architectural  feature  discussed  in  the  following  paragraphs. 

3. 1.2.1  Throughput 

SDC  minimized  the  risk  that  the  architecture  will  not  have  sufficient  computing 
power  in  several  different  ways: 

a.  SDC  has  chosen  a general  purpose  processor  size  (3.5  X 1108)  that 

is  well  within  the  mainstream  of  the  data  processing  community.  The 
performance  of  such  processors  is  less  dependent  on  special  features 
than  the  very  large  systems,  and  this  provides  assurance  that  promised 
throughput  rates  can  be  easily  achieved. 

b.  For  key  driving  requirements  that  need  extremes  of  processing  power, 

SDC  has  chosen  to  use  array  processors.  In  general,  high  MIP  appli- 
cations fail  due  to  insufficient  compute  power.  Array  processors, 
which  take  advantage  of  problem  characteristics,  can  supply  many  times 
the  effective  computing  power  that  general  purpose  CPU's  can  provide. 

In  addition,  the  array  processors  are  modularly  expandable  to  addi- 
tional levels  of  compute  speed  at  reasonable  increments  in  cost.  This 
is  a vital  characteristic  in  the  solution  of  problems  that  are  so 
complex  that  they  must  actually  be  implemented  to  determine  compute 
levels  with  accuracy. 

c.  By  1982,  AFGWC  must  support  several  time-critical  requirements  simul- 
taneously. SDC  has  chosen  an  architecture  utilizing  multiple  CPU's 
to  minimize  potential  conflicts  due  to  security  levels  and/or  pro- 
cessing time.  The  network  can  be  segmented  (by  1982)  into  ten  distinct 
processors,  five  of  which  can  act  as  hosts  to  array  processors.  This 
provides  assurance  that  multiple  satellite  passes  can  be  mapped  and 
gridded,  multiple  numerical  models  can  be  run,  and  multiple  security 
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levels  can  be  maintained  concurrently.  Architectural  alternatives 
such  as  fewer  but  larger  general  purpose  processors  would  have  a 
higher  rate  of  failing  to  handle  such  conflicts. 

d.  The  system  is  normally  run  with  main  processor  systems  operating  in 
a multiprocessor  mode  for  greater  reliability  and  simple  scheduling. 

These  multiprocessor  systems  have  less  throughput  than  dual  unipro- 
cessor systems  due  to  such  problems  as  memory  conflicts.  This  means 
that  the  system  has  potential  reserve  computing  power  which  has  not 
been  counted  on  in  design  estimates.  By  1982,  this  reserve  will 
reach  2.5  times  the  performance  of  an  1108  (2.5RP  * 10  X 2RP  - 5 X 
3.5RP;  a multiprocessor  derati ng*f actor  of  .9  is  standard,  giving 
2-2RP  uniprocessors  a rating  of  .9X2X2RP  = ~ 3.5RP  in  multiprocessor 
mode ) . 

Throughput  areas  which  have  a higher  than  average  risk  are  listed  below. 

Data  Upgrade  Link  - This  link  is  a solution  to  the  problem  of  an  N2 
interconnection  matrix,  where  N is  the  number  of  processors.  In  the 
architecture,  processors  span  a large  number  of  functions  and  security 
levels.  Because  of  this,  each  processor  must  be  able  to  send  data  to 
each  other  when  the  data  path  is  from  a lower  to  a higher  security 
level.  To  avoid  an  N2  proliferation  of  channel  interconnections,  SDC 
has  used  a control  upgrade  path.  This  "wagon  wheel"  approach  requires 
only  one  channel  from  each  of  N processors.  This  data  path  has  a 
throughput  requirement  that  is  not  sizable  from  operational  require- 
ments. The  risk  seems  small  that  channel  speeds,  delayed  by  cascaded 
encryption,  will  be  insufficient. 

Disk  Interface  - The  risk  associated  with  the  disk  interface  stems  from 
the  large  number  of  processors  that  must  have  an  access  path  to  disk 
storage.  This  risk  is  higher  than  average  because  the  number  of 
processors  that  must  be  wired  into  a single  disk  string  exceeds  that 
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found  in  normal  data  systems.  The  risk  is  one  of  potential  bottlenecks 
rather  than  a hardware  feasibility  problem.  Off-the-shelf  hardware  can 
be  used  to  provide  multiple  paths,  expandable  to  enormous  powers  of  two. 
No  more  processors  need  be  acti ve  on  a disk  string  than  is  normally 
accomplished  in  a large  number  of  installations,  however.  SDC  has 
minimized  the  risk  here  by  specifying  multiple  controllers  (additional 
paths  to  disk  storage)  and  combination  disks  where  the  most  frequently 
accessed  data  is  kept  on  fixed  heads, areas  reducing  the  potential  of 
conflict. 

In  part,  the  risk  stems  from  the  very  detailed  hardware  levels  that  must 
be  understood  to  make  a judicious  choice  of  vendor  and  configuration. 
Additionally,  the  risk  stems  from  the  possibility  that  CPU's  from 
different  vendors  must  use  the  same  disk,  with  problems  in  word  length, 
disk  format,  access  methods,  etc.  This  latter  risk  can  be  minimized  by 
staging  with  IBM  plug  compatible  disks,  which  have  become  the  industry 
standard. 

Authentication  Devices  - Authentication  devices  represent  SDC's  only 
departure  from  the  use  of  existing  commercial  capabilities.  SDC 
believes,  after  discussion  with  hardware  vendors,  that  this  capa- 
bility will  shortly  be  available  with  transfer  rates  matching 
channel  capacity.  SDC  has  also  confirmed  the  existence  of  non- 
commercial devices  that  have  the  necessary  characteristics.  If,  for 
some  reason,  authentication  devices  were  not  brought  out  commercially, 
these  other  devices  could  be  used  instead.  The  impact  would  primarily 
be  an  increase  in  the  cost  per  device  and  the  need  for  detailed 
systems  engineering  to  insure  compatibility  with  disk  interface 
protocol,  access  methods  and  diagnostics.  SDC  feels  confident  that 
a commercial  capability  will  be  available  shortly  and  has  therefore 
costed  these  devices  at  projected  unit  prices  in  all  architecture 
cost  estimates. 
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Cable  Lengths  - Careful  physical  planning  will  be  required  to  insure  that 
maximum  cable  lengths  are  not  exceeded  in  providing  system  interconnections. 
Cable  lengths  can  be  extended  in  most  cases  with  line  drivers,  but  these 
have  not  been  costed  because  their  cost  is  small  compared  to  the  overall 
data  system  cost  and  because  SDC's  physical  planning  with  generic  compo- 
nents  indicates  that  there  is  no  need  for  line  drivers.  Maximum  cable 
lengths  should,  however,  be  an  evaluation  criteria  in  equipment  selection 
because  this  single  feature  has  great  Impact  on  flexibility.  This  is 
especially  true  of  processor  to  disk  cabling  because  the  more  data  bases 
a processor  can  be  cabled  to,  the  more  functions  can  be  performed  on  that 
processor;  this  simplifies  scheduling,  minimizes  the  probability  of 
unresol vable  conflicts  (security  or  loading),  and  aids  in  failure  recovery. 

While  the  probability  of  failure  is  low,  the  cost  impact  is  high,  giving 
this  area  a higher  than  average  risk.  (SDC  has  used  150  feet  as  maximum 
channel  cable  lengths.) 


3. 1.2. 2 Storage  Capacity 

The  primary  architectural  feature  which  minimizes  the  risk  that  storage  capacity 
will  be  insufficient  is  the  Mass  Storage  Facility.  The  Mass  Storage  Facility 
acts  as  an  extension  of  disk  storage  by  moving  data  sets  to  and  from  disk 
without  main  processor  intervention  on  a demand  basis;  this  action  is  called 
"staging".  Data  sets  are  staged  to  disk  prior  to  the  execution  of  jobs 
requiring  them.  Disk  data  sets  not  in  use  are  de-staged  to  a slower,  far  less 
expensive  media  to  make  room  for  active  data  sets.  The  criteria  for  releasing 
data  sets  is  called  the  "least-recently-used"  algorithm,  used  in  virtual  memory 
machines  for  paging  of  main  memory.  In  this  respect,  the  Mass  Storage  Facility 
provides  an  extension  of  virtual  memory  to  another  hierarchy  of  storage.  With 
this  capability,  disk  space  becomes  a tuning  parameter  rather  than  a hard-and- 
fast  limitation. 
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In  addition  to  the  Mass  Storage  Facility  minimizing  the  risk  of  insufficient 
storage  capacity,  projected  technological  advancement  indicates  that  disk 
capacities  will  double  or  quadruple  within  the  1977-1987  period.  The  cost 
per  disk  will  be  minimally  increased  to  protect  rental  revenues,  but  the 
cost  per  character  stored  will,  of  course,  be  approximately  a half  or  fourth 
of  what  it  was  before. 

3. 1.2.3  Reliability 

The  risk  of  an  unreliable  data  system  has  been  minimized  through  several 
standard  techniques,  such  as  use  of  redundant  critical  components  and  design 
to  a peak  load.which  provides  additional  throughput  for  failure  recovery. 

In  addition,  several  technological  features  inherent  in  the  components  avail- 
able today  offer  increased  reliability.  The  clear  trend  of  hardware  manu- 
facturers is  to  provide  higher  reliability.  By  staying  within  the  main- 
stream of  the  data  processing  community,  SDC  has  allowed  AFGWC  to  take 
advantage  of  these  improvements.  For  example,  the  IBM  plug-compatible  3340- 
type  disks  (an  example  of  the  combination  disk  used  in  the  architecture)  requires 
no  preventive  maintenance  and  is  capable  of  detecting  and  correcting  errors  up 
to  3 bits  long  per  record.  Also,  it  seems  clear  that  semiconductor  memory 
prices  are  dropping  rapidly  on  a per  bit  basis,  and  that  this  cost  savings  will 
be  used  to  provide  better  error  correction  and  detection  techniques  for  main 
memory.  Since  most  processor  hardware  failures  are  due  to  memory  errors,  this 
trend  promises  dramatic  reliability  increases  for  main  processor  systems. 
Executive  systems  are  also  showing  a decrease  in  failure  rate  due  to  maturing 
of  code, use  of  structured  programming, and  the  use  of  self-repair  techniques. 

There  is.  an  area  of  reliability,  however,  in  which  a higher  than  average  risk 
exists.  The  direction  of  the  Industry  is  towards  remote  debugging  of  main 
processors  from  a remote  central  location.  Security  constraints  dictate  that 
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this  is  not  possible  at  AFGWC.  The  impact  of  this  is  a possibility  that  SDC 
estimates  of  vendor  supplied  maintenance  will  be  low.  The  risk,  of  course, 
increases  towards  the  end  of  the  study  period.  At  this  time,  no  cost  estimates 
can  be  realistically  assessed  for  this  trend,  and  so  SDC  has  used  traditional 
maintenance  values.  (For  more  information  on  this  subject,  see  the  Security 
Considerations  paragraph  of  the  introduction  to  the  AGE  Plan,  Volume  6.) 

In  software,  the  reliability  risk  is  higher  than  average  for  Network  Control 
and  Central  Data  Base  Management  because  the  entire  network  of  computers  is 
affected  by  a failure  of  either  of  these  software  modules.  This  risk  can 
be  minimized  by  proper  design  of  the  code,  with  reliability  and  recovery  an 
integral  feature  of  the  processing. 

3. 1.2. 4 Operation 

Due  to  the  increase  in  requirements,  the  AFGWC  data  system  will  increase  con- 
siderably in  size  and  complexity  from  1975  to  1982.  The  attendant  risk  is 
that  it  will  become  unwieldy  from  an  operational  viewpoint.  SDC  has  minimized 
this  risk  by  grouping  functionally  related  operations  into  centralized  work 
centers,  by  providing  a network  control  capability,  and  by  routing  production 
messages  to  concerned  personnel  directly  rather  than  through  a console  operator. 

3. 1.2. 5 Security 

The  risk  of  security  violations  has  been  minimized  in  several  ways: 

First,  mixed-mode  security  has  not  been  used  with  one  exception:  because 
an  individual  communication  line  can  carry  messages  at  several  security 
levels,  the  line  handler  decoder  routers  must  have  mixed-mode  security. 

This  exception  is  imposed  on  the  architecture  by  the  presence  of  mixed- 
mode in  external  systems. 

Second,  manual  handling  of  multiple  security  levels  has  been  restricted  to 
low  traffic  levels.  Printers  have  been  provided  for  all  security  levels  to 
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avoid  bursting  errors.  Tape  drives  have  been  specified  to  have  visible 
indicators  that  display  security,  and  all  unclassified  tapes  are  handled 
via  a separate,  automated  facility.  The  high  transfer  volume  needed  for 
the  data  upgrade  path  has  been  provided  by  an  automated  facility  using 
channel  transfer  through  cascaded  authentication  devices. 

Third,  authentication  devices  have  been  used  to  prevent  inadvertent  access 
of  classified  Information.  These  devices  are  highly  reliable  hardware 
with  fail-safe  characteristics. 

3.2  COST 

SDC  has  minimized  the  risk  of  the  data  system  exceeding  estimated  cost  in 
several  ways.  First,  all  hardware  cost  were  estimated  conservatively  by  using 
a maximum  cost  within  a category  of  equipment  rather  than  an  average.  Second, 
SDC  has  chosen,  almost  without  exception,  existing  hardware  capabilities  and 
so  the  costs  can  be  estimated  with  high  accuracy.  Third,  the  technological 
trend  is  strongly  towards  more  performance  per  dollar  indicating  that  despite 
inflation,  the  actual  hardware  costs  will  average  less  than  SDC  has  projected. 

Software  cost  risk  was  also  reduced  by  a conservative  approach.  The  enhanced 
architecture  has  been  specified  with  two  powerful  tools  for  increasing  pro- 
grammer productivity,  interactive  (online)  programming  and  structured 
programming. 

Software  costs,  however,  were  estimated  with  the  minimum  improvement  in  pro- 
ductivity needed  to  cost-justify  the  investment  in  these  two  techniques.  In 
addition,  SDC  has  specified  main  and  support  processors  that  are  well  within 
the  general  commercial  capabilities.  As  a result,  AFGWC  is  assured  of 
reliable  executives,  a full  range  of  software  facilities,  and  essential  soft- 
ware development  tools. 
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Cost-benefit  analyses  were  also  very  conservative  and  use  the  least-favorable 
conditions  rather  than  typical  or  most-favorable  ones.  By  using  the  minimum 
justification  and  the  fastest  payback  period,  the  risk  that  an  architectural 
feature  will  not  prove  to  be  cost  effective  was  minimized.  An  example  of  this 
is  the  Mass  Storage  Facility  which  was  justified  on  a basis  of  manpower  savings 
over  only  a year,  whereas  the  savings  will  accrue  over  a longer  period  and  will 
also  come  from  other  than  manpower  reduction. 

Two  areas  of  cost  stand  out  as  having  higher  than  average  risk.  First,  authen- 
tication devices  are  not  yet  commercially  available,  as  discussed  under  3. 1.2.1 
Second,  maintenance  costs  are  a function  of  salaries  as  well  as  technology  and 
are  indicating  a 3-4%  rise  every  year.  This  is  less  than  the  current  inflation 
rate  and  so  represents  an  actual  drop  in  cost  in  constant  (inflation-adjusted 
to  1975)  dollars.  Hence,  SDC  has  been  conservative  by  assuming  a constant 
maintenance  fee  in  1975  dollars.  These  conditions  may  not  always  prevail, 
however.  This  risk  is  also  increased  by  a trend  toward  remote  debugging  as 
discussed  in  3. 1.2. 3 and  in  the  introduction  to  the  AGE  plan.  Volume  6 of  this 
final  report.  (Because  AFGWC  security  constraints  eliminate  the  possibility 
of  remote  trouble-shooting,  more  than  the  typical  number  on-site  customer 
engineers  may  be  required,  resulting  in  an  additional  unpredictable  cost.) 


3.3  SCHEDULE 

By  using  existing  haraware  capabilities,  schedules  for  hardware  delivery  have 
been  virtually  eliminated  as  a risk  factor. 

Physical  plant  expansion  beyond  current  plans  is  unnecessary  as  all  components 
and  maintenance  areas  fit  within  the  planned  space.  This  eliminates  the  risk 
of  failure  to  meet  schedule  due  to  construction,  a lengthy  process  for  AFGWC. 


The  risks  of  not  meeting  software  schedules  was  minimized  as  follows: 

a.  The  use  of  contracted  software  was  specified  for  50%  of  the  effort, 
alleviating  USAF  manpower  constraints. 

b.  Techniques  were  specified  for  increasing  programmer  productivity  and 
lowering  maintenance  activity  on  code  via  training,  structured  pro- 
gramming, on-line  programming,  and  an  improved  test  plan. 

c.  SDC  assumed  no  slippage  of  requirements,  although  several  key  require- 
ments have  a high  probability  of  a late  realization. 

3.4  MISSION  SUITABILITY 

Mission  suitability  is  primarily  a question  of  having  the  flexibility  to  accomo- 
date changing  requirements  and  growth.  The  enhanced  architecture  has  several 
features  which  provide  flexibility  in  meeting  requirements: 

a.  Network  Control.  The  central  scheduling  and  status  monitoring  capa- 
bilities of  the  Network  Control  function  provide  an  ability  to  react 
to  changing  workloads  or  priorities. 

b.  Security  Approach.  Processors  can  be  quickly  changed  from  one  security 
level  to  another  due  to  the  authentication  devices  and  the  modulariza- 
tion of  the  network  into  main  processor  subsystems  that  contain  only 
rapidly  cleanable  devices.  This  allows  flexibility  in  applying 
resources  at  differing  security  levels. 

c.  External  Interfaces.  The  major  resources  of  the  computer  network, 
the  main  processor  subsystems,  are  decoupled  from  external  interfaces 
because  work  is  logged  into  the  data  system  through  the  disk  sub- 
systems. Main  processors  are  not  directly  on-line  to  any  external 
communication  lines  or  support  processors  (the  one  exception  is  the 
programmer  consoles  which  will  be  directly  linked  to  preserve  vendor- 
supplied  software  support).  Thus,  changes  to  communication  links  are 
isolated  to  the  communication  subsystems,  and  even  total  replacement 
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of  line  handler  data  router  hardware  will  not  affect  the  main  pro- 
cessor interface  to  the  outside  world  (as  they  still  will  be  linked 
only  to  the  disks).  The  use  of  disks  as  an  interface  also  provides 
timing  and  loading  isolation.  Support  processors  can  be  modified  or 
increased  in  number  (as  well  as  fail, or  change  missions)  without  a 
hardware  or  software  impact  within  the  main  processor  subsystems. 

Centralized  Data  Bases.  Data  bases  for  a given  function  are  central- 
ized into  subsystems;  e.g.,  meteorological  and  satellite  data  base 
subsystems.  This  provides  for  modular  growth  of  a data  base  without 
the  cost  being  multiplied  by  repetition  on  each  processor  system. 

It  also  allows  easy  expansion  of  the  number  or  power  of  processor 
subsystems.  Multiple  computers  can  be  brought  to  bear  in  a functional 
area,  such  as  satellite  data  mapping  and  gridding  because  the  data 
base  is  centralized  and  shared. 


In  addition  to  the  need  fcy'  flexibility  to  accommodate  change,  there 
is  the  need  to  avoid  the  risk  of  designing  an  architecture  that  is 
obsolete  due  to  technological  advancement.  Without  proper  safeguard, 
a 1975  design  could  be  totally  inappropriate  by  1982.  SDC  has  mini- 
mized the  risk  of  obsolescence  by  examining  technology  projections 
(e.g.,  SADPR-85)  and  by  obtaining  proprietary  information  from  vendors 
under  non-disclosure  agreements.  This  information  was  discussed  during 
formal  briefings  and  will  not  be  treated  here.  The  result  of  the  SDC 
investigation  has  been  an  architecture  that  allows  AFGWC  a growth  path 
compatible  with  the  foreseeable  direction  of  the  Industry. 


3.5  SCOPE 


Scope  is  the  ability  to  encompass  all  requirements  and  treat  all  aspects  of  the 
data  system.  SDC  emphasized  scope  In  the  Task  1 briefing  as  a characteristic 
of  both  Task  1 and  the  succeeding  tasks.  The  use  of  the  requirement,  functional, 
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and  architectural  domains  as  organizational  frameworks  provided  a mechanism 
for  insuring  that  the  architecture  was  treated  from  all  perspectives.  Addi- 
tionally, the  flexibility  and  throughput  of  the  enhanced  architecture,  as 
previously  discussed,  are  guarantees  of  the  ability  to  supply  a total  range 
of  support  to  AFGWC  customers. 


4.0  SYSTEM  VERIFICATION  PLANNING 


The  delivery  and  integration  of  a complex  hardware/software  system  is  supple- 
mented by  independent  integrated  test  disciplines  which  should  ensure  that 
the  enhanced  architecture  implementation  meets  all  functional  and  technical 
performance  requirements  presented  in  the  system  specification.  Essential 
follow-up  to  the  specification  requirements  for  the  AFGWC  architecture  are 
the  testing  approaches  which  assure  the  installation  of  a quality  system  in 
a controlled  and  timely  manner. 

The  following  sections  outline  system  verification  philosophy  disciplines  for 
both  hardware  components,  software  components,  and  the  integrated  system  which 
will  insure  this  level  of  integration. 

4.1  SYSTEM  TESTING  PHILOSOPHY 

4.1.1  Test  Evolution 

The  first  things  that  need  to  be  established  are  the  steps  of  the  total  test 
planning  effort.  These  steps  are  identified  as  follows: 

a.  Test  Requirements.  This  step  is  a production  of  a document  either  by 
the  government  or  by  an  outside  vendor.  The  basis  for  the  test 
requirements  document  depends  on  the  nature  of  the  procurement  of 
components  of  the  architecture  and  the  relationship  of  the  testing 
to  that  procurement  or  procurements  (part  of  the  fulfillment  of  the 
delivery  or  level  of  effort).  Depending  on  the  circumstances,  the 
design  specification  may  be  used  as  a first  iteration;  however,  test 
specifications  normally  deviate  from  design  specifications  since 
some  design  specifications  are  non-testable,  others  are  trivial,  and 
often  the  design  encompasses  details  testable  at  a lower  level  than 
was  originally  specified. 
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b.  Test  Planning.  As  in  the  management  of  any  large  effort,  a test  plan 
is  written  which  identifies  the  conduct  of  tests,  the  relations 
between  tests  (in  the  form  of  a network  analysis  of  the  total  effort), 
a philosophy  of  verification  by  the  government  as  well  as  other 
management  details  (see  Section  4.5.1).  Because  of  the  inter- 
dependencies in  testing  and  the  high  probability  that  events  will 

not  progress  according  to  schedule,  test  planning  is  very  important. 

c.  Test  Description.  In  this  effort,  the  organization  doing  the  testing 
describes  in  detail  how  the  test  requirements  are  to  be  met.  This 
description  gives  the  test  procedures  for  every  test  including 
parameters,  data,  and  verification  procedures  (see  Section  4.5.2). 

(It  is  recommended  that  the  test  procedures  be  written  in  two  parts: 
first  the  overview,  and  then  more  detailed  description  in  order  to 
accommodate  a total  review.) 

d.  Test  Accomplishment.  During  actual  testing  (depending  on  the  size 
of  the  effort  and  the  dependency  and  the  detail  to  which  the  test 
process  needs  to  be  observed),  this  effort  must  be  documented  in 
detail.  A testing  configuration  management  board  is  essential,  and 
must  have  the  authority  to  change  schedules,  monitor  activity,  and 
report  progress. 

e.  Test  Analysis  and  Documentation.  The  outputs  and  products  test  are 
then  analyzed  and  formally  documented. 


4.1.2  Test  Concepts 

The  overall  test  concept  which  SDC  recommends  is  a top  down  approach  (usually 
following  the  top  down  design  if  applicable).  In  this  type  of  testing  the 
component  residing  at  the  higher  level  of  abstraction  is  tested  with  all  other 
components  at  that  same  level  of  abstraction.  Components  existing  at  a higher 
level  (in  this  case,  components  and  modules  are  synonomous)  will  have  already 
been  tested  and  those  at  a lower  level  have  yet  to  be  tested.  The  existence 
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of  components  at  a lower  level  will  be  simulated  using  small  simulation  pack- 
ages called  "stubs"  which  effectively  act  as  if  they  were  the  lower  level. 
Hopefully  the  definition  of  the  module  was  such  that  it  could  be  tested  inde- 
pendently and  simply;  however,  if  this  is  not  the  case,  preparation  for  testing 
at  a single  level  might  be  extensive.  In  this  case,  within  a module,  a bottom 
up  testing  scheme  is  utilized  where  the  smallest  pieces  are  tested  individually 
then  gradually  put  together  into  a package.  This  also  describes  exactly  how 
the  components  at  a single  level  are  tested,  first  individually  and  then  put 
together  one  at  a time. 


The  various  levels  of  testing  are  applied  no  matter  what  size  the  development; 
however,  in  some  cases,  especially  in  small  developments,  the  levels  are  run 
together. 

a.  Component  Checkout.  The  first  level  of  testing  is  called  component 
checkout  and  is  usually  accomplished  by  the  programmer.  This  is  the 
testing  of  the  individual  components  in  either  static  or  dynamic 
states. 

b.  Validation  Testing.  This  is  the  ongoing  testing  effort  that  tests 
levels  of  abstraction  until  the  entire  system  has  been  tested.  This 
level  precisely  follows  the  test  plan. 

c.  Acceptance  Testing.  In  cases  where  the  operational  element  of  the 
buyer  are  different  than  the  agencies  doing  the  developing,  acceptance 
testing  is  the  name  given  for  the  demonstration  that  the  product  works 
as  advertised.  This  is  accomplished  by  selecting  a reasonable  set  of 
validation  tests  to  be  performed. 

d.  Integration  Testing.  Where  there  are  several  contractors,  several 
subsystems,  or  hardware  and  software  being  procured  simultaneously, 
the  testing  effort  which  integrates  these  into  a sinqle  system 

is  called  integration  testing.  It  can  be  accomplished  using  the 
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philosophies  described  earlier,  and  as  before,  requires  a complete 
set  of  documentation  and  planning. 

e.  Rehearsal.  This  phase  of  testing  is  the  linking  of  man  to  machine  and 
programs.  This  is  the  test  in  which  the  final  users  of  the  system  run 
the  system  and  the  builders  of  the  system  are  available  for  assistance. 

4.2  HARDWARE  COMPONENT  CHECKOUT 

The  hardware  associated  with  AFGWC  data  system  architecture  can  be  viewed  as 
either  commercial  or  program  unique  equipment.  Program  unique  equipment  is 
subject  to  the  same  validation  procedures  as  commercial  equipment  after  it 
goes  into  production.  The  following  hierarchy  of  hardware  testing  will  provide 
AFGWC  with  the  highest  probability  of  a successful  integration  of  the 
architecture. 

4.2.1  Component  Testing 

This  testing  consists  of  reviewing  the  hardware  element  In  both  static  and 
dynamic  states.  This  inspection  will  be  performed  during  and  immediately 
after  manufacture.  When  appropriate,  this  will  include  the  use  of  reliability 
and  diagnostic  systems  provided  by  the  manufacturer.  This  level  of  testing 
includes:  (a)  Bench  tests  performed  using  standard  lab  equipment  (oscillo- 

scopes, waveform  generators,  etc.)  to  verify  unit  performance;  and  (b)  Tests 
performed  in  a test  bed  environment,  sometimes  requiring  special-purpose  test 
equipment  (e.g.,  data  generators,  displays,  etc.)  to  verify  assembly  performance 
specifications  (e.g.,  throughput,  bit  error  rate,  code  conversion,  etc.). 

4.2.2  Hardware  Integration  Tests 

This  series  of  tests  will  be  performed  at  a subsystem  and  system  level.  As 
individual  components  are  integrated  into  subsystems  and  systems,  the  manu- 
facturer will  provide  viable  techniques  for  ensuring  that  the  design  performance 
continues  to  be  adhered  to.  This  level  of  testing  Includes: 
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a.  Subsystem  Testing.  Tests  performed  in  a test  bed  environment, 
generally  requiring  special-purpose  test  equipment  for  interface 
simulation,  to  verify  subsystem  performance  specifications.  Also 
reverifies  assembly  performance  in  a subsystem  environment. 

b.  System  Testing.  The  final  phase  of  testing  is  the  assembling  of  the 
set  of  subsystems/systems  and  verifying  that  these  subsystems/systems 
will  support  the  mission  which  has  been  specified  in  the  operational 
requirements;  i.e.,  the  AFGWC  architecture  as  it  is  specified  in 

the  specification  requirements. 

If  software  components  are  necessary  at  this  level  of  testing  and  the  opera- 
tional software  is  still  in  the  development  stage,  the  manufacturer  should 
provide  simulation  software  drivers  that  can  support  this  testing  effort. 

This  level  of  testing  should  verify  the  hardware's  capacity  to  support  the 
system  integration  tests  and  formal  demonstrations. 

4.3  SOFTWARE  COMPONENT  CHECKOUT 

Two  major  categories  of  tests  will  be  utilized  for  the  testing  of  software 
components  for  the  enhanced  AFGWC  architecture.  The  two  major  categories  are: 
(a)  functional  testing,  and  (b)  performance  testing. 

4.3.1  Functional  Testing 

Functional  testing  is  an  exhaustive  one-for-one  test  of  each  cause  that  can 
produce  an  effect  or  a test  for  each  and  every  condition  that  can  occur. 

Functional  testing  can  be  divided  into  the  following  subcategories:  new 
function  testing,  functional  regression  testing,  and  functional  stress  testing. 
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New  function  testing  refers  to  the  testing  that  must  be  done  to  new  programs 
or  changes  to  existing  programs  to  verify  their  new  capabilities.  For  each 
new  function  or  change  to  a function,  a test  or  series  of  tests  must  be 
designed  to  exercise  that  new  function  to  ensure  it  operates  correctly.  This 
becomes  a particularly  involved  problem  in  a meteorological  environment  such 
as  AFGWC's.  The  large  grids,  vast  amounts  of  input  data,  and  many  time  steps 
or  successive  iterations  make  it  no  easy  task  to  ensure  that  a function  is 
operating  correctly.  Often,  it  may  be  impossible  to  predetermine  what  "correct" 
behavior  is.  Meteorological  models  which  are  driven  by  complicated  mathematical 
algorithms  may  appear  to  be  malfunctioning  when  in  fact  it  is  only  the  pro- 
grammer's understanding  of  the  physics  involved  which  is  in  error.  Once  a 
new  capability  is  verified,  it  still  must  be  determined  whether  the  chanqe  has 
inadvertently  affected  another  phase  of  the  function's  operation;  for  example, 
it  can  now  predict  temperature  changes  within  a tenth  of  a degree  as  expected, 
but  has  unexpectedly  lost  the  ability  to  predict  vertical  winds.  New  function 
testing  must  involve  as  a minimum  the  following: 

a.  Identification  of  all  new  capabilities  provided. 

b.  A manual  analysis  of  the  changes  the  new  capabilities  should  generate. 

c.  Testing  of  the  new  capabilities  with  a wide  cross-section  of  input 
data. 

d.  Successive  iterations  of  the  new  function  (if  it  feeds  on  itself) 
out  to  the  farthest  point  feasible,  with  careful  examination  of  the 
outputs  at  each  step. 

e.  A functional  regression  testing  on  other  portions  of  the  function 
which  should  remain  unchanged  or  on  functions  which  use  the  new 
output  as  a source  for  their  data. 

Functional  regression  testing  will  verify  that  unmodified  elements  of  the 
environment  remain  intact  and  that  there  have  been  no  changes  caused  by  the 
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modification  of  other  elements  of  the  function.  In  order  to  accomplish  this 
testing,  complete  functional  regression  testing  must  be  performed  against  all 
programs  once  any  element  of  that  environment  has  been  modified.  The  number 
of  functional  regression  tests  for  any  particular  function  will  be  directly 
correlated  with  the  size  of  the  function.  There  may  be  one  or  several  hundred 
tests  associated  with  each  major  change. 

This  form  of  testing  will  ensure  that  errors  are  located  and  corrected  in  the 
test  environment  and  that  any  modifications  presently  performed  on  the  system 
will  not  affect  any  previous  system  capabilities  other  than  those  in  the 
desired  modification.  The  fundamental  concept  of  regression  testing  is  that 
each  and  every  test  case  that  is  run  successfully  against  the  old  unmodified 
code  must  produce  identical  results  when  run  against  the  modified  code.  A 
related  type  of  testing  involves  the  determination  that  an  unmodified  element 
will  not  be  harmfully  effected  by  data  which  is  now  defunct  (but  hopefully 
better)  produced  by  an  element  which  has  been  modified.  This  would  be  the 
type  of  regression  testing  referred  to  in  step  e.  of  the  paragraph  describing 
new  function  testing.  When  such  changes  in  new  data  are  injected,  the  basic 
premise  of  regression  testing  cannot  be  met  since  it  is  unlikely  that  two 
different  data  sets  will  produce  the  same  results.  The  task  becomes  more 
difficult,  since  changes  must  be  predicted  and  these  used  as  the  goal  of 
regression.  Since  many  functional  changes  at  AFGWC  involve  enhancements  in 
the  actual  data  rather  than  just  changes  in  the  manner  they  are  calculated, 
this  type  of  testing  cannot  be  overlooked.  It  is  preferred  that  regression 
testing  be  run  in  automated  manner,  using  system  simulation  or  other  verifica- 
tion resources.  The  work  load  would  be  intolerable  if  the  tests  were  run  in 
the  manual  mode.  If  during  this  testing,  a regression  or  an  error  occurs,  the 
new  code  must  be  corrected  or  made  compatible  with  the  old  code  in  order  that 
the  test  can  run  as  planned. 
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Functional  stress  testing  will  ensure  that  the  system  can  respond  under  heavy 
loading  conditions  as  it  does  in  the  low  load  condition  as  performed  in  both 
the  new  function  testing  and  the  functional  regression  testing.  Often,  pro- 
grams will  execute  properly  under  minimal  loading  conditions  but  will  fail 
when  the  system  is  heavily  loaded.  Functional  stress  testing  is  used  to 
locate  this  type  of  a failure.  Given  the  wide  range  of  loading  found  in  AFGWC 
computers,  stress  testing  is  very  important  to  ensure  functions  will  not  err 
at  what  could  be  the  worst  time. 

4.3.2  Performance  Testing 

Performance  testing  will  attempt  to  recreate  or  simulate  a specific  AFGWC 
production  environment.  The  specific  test  will  be  derived  or  produced  from 
user  profiles  provided  by  AFGWC.  Performance  testing  can  be  divided  into  the 
following  subcategories:  performance  load  testing,  regression  performance 

testing,  and  performance  measurement  testing.  The  desirability  of  performance 
testing  cannot  be  overlooked.  With  Network  Control  handling  the  allocation 
of  functions,  particular  elements  could  find  themselves  competing  for  resources 
under  many  conditions.  If  the  conflicts  can  be  determined  in  advance,  then 
Network  Control  can  be  prepared  to  resolve  such  conflicts. 

Performance  load  testing  will  determine  whether  or  not  the  programs  that  have 
been  modified  or  newly  implemented  can  indeed  handle  the  planned  load  with 
adequate  throughput  and  an  acceptable  response.  It  is  important  that  this 
capability  be  tested  in  a test  environment  rather  than  the  production  environ- 
ment. It  is  extremely  important  to  this  type  of  testing  that  accurate  profiles 
be  established.  Otherwise  programs  may  appear  to  execute  adequately  in  the 
test  environment,  but  fail  in  the  actual  production  environment. 

Regression  performance  testing,  again,  tests  whether  or  not  newly  modified 
code  or  implemented  code  effects  capabilities  and  capacities  in  the  previous 
system.  This  type  of  testing  is  conducted  to  determine  the  extent  of  change 
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in  throughput  and  response  on  any  portion  of  the  environment  that  has  been 
modified.  If  for  some  reason,  the  throughput  is  not  acceptable,  changes  to 
the  system,  either  to  the  newly  implemented  or  the  previously  existing  system, 
are  necessary. 

Performance  measurement  testing  is  performed  in  order  to  locate  critical 
bottlenecks  in  the  system  and  aids  the  system  designers  in  tuning  the  system 
for  the  production  environment.  In  this  particular  type  of  test,  various 
systems  parameters  will  be  varied  and  measurements  can  then  be  made  to  show 
the  effect  of  the  new  code  on  both  response  and  throughput.  This  contrived 
environment  is  really  in  no  way  representative  of  any  production  environment. 
It  is,  however,  an  experimental  environment  which  causes  certain  effects  to 
become  obvious  in  the  newly  implemented  code. 

4.4  SYSTEM  DEMONSTRATION 

System  demonstration  will  perform  an  integrated  test  on  both  the  hardware  and 
software  components  of  the  AFGWC  architecture.  Demonstration  will  consist  of 
both  the  dynamic  operation  of  increments  of  the  system  and  of  the  system 
itself.  Verification  techniques  utilized  for  the  system  demonstration  will 
be  via  both  system  displays  and  other  input  and  output  devices.  System 
demonstration  is  the  final  step  in  establishing  that  all  AFGWC  requirements 
are  verified.  It  consists  primarily  of  repeatedly  exercising  the  system 
under  realistic  conditions  and  carefully  reviewing  all  operations  and  outputs 
for  any  anomalies.  Both  off-line  manual  examination  of  the  data  and  computer 
analysis  of  the  test  results  are  recommended  for  the  AFGWC  architecture. 


4.5  SYSTEM  TEST  PLANNING 

Each  level  of  testing  associated  with  the  enhanced  AFGWC  architecture  comprises 
a similar  set  of  activities.  For  each  level,  the  activities  to  be  performed 
are  as  follows: 
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a.  Develop  test  plan 

1)  Identify  all  input/output  data  paths. 

2)  Identify  program  tasks  (requirements,  interfaces/functions)  to 
be  tested. 

3)  Delineate  validation  methods  to  be  employed  (i.e.,  inspection, 
analysis,  demonstration,  or  usage). 

4)  Identify  types  and  sources  of  acceptance  criteria,  and  tolerances 
where  applicable. 

/ 

5)  Specify  test  tools,  equipment  jzonfigu rations,  an^organizational 

. • f ; / f ( f ' r 

roles.  / / / / / , // 

6)  Specify  test/data  requirements/ 

7)  Schedule  te/t  activities.  /' 

/ / ■ 

b.  Develop  test  procedures 

/ / / / 

1)  Acquire  t^6st  tools. 

2)  Generate  test  data  (as  required).  / 

/ 7 

3)  Design  test  cases. 

' X 

4)  Specify  acceptance  criteria  and  tolerances  where  applicable. 

/ * 

" / 

c.  Conduct  tests. 

' //■ 

d.  Prepare  test  analysis  and  generate  report,  analyzing  performance 
against  criteria. 

4.5.1  Test  Plan  Development 

The  test  plans  will  provide  the  following: 

a.  Identification  of  All  Input/Output  Data  Paths.  All  input/output  data 
paths  will  be  identified.  "Data"  in  this  case  also  includes  parameters, 
conditions  of  indicators,  results  of  logical  tests,  or  any  other  con- 
trolling input  or  output. 


if  . 


• *■  v. 


While  for  component  level  testing,  there  is  some  latitude  available 
in  the  determination  of  material  to  be  explictly  tested,  the  decision 
for  implicit  testing  should  not  be  taken  lightly,  since  the  time  to 
determine  whether  requirements  have  been  properly  satisfied  or 
whether  the  integrity  of  interfaces  has  teen  maintained  is  during 
this  level  of  testing. 

b.  Identify  Program  Tasks  (requirements,  interfaces  and  functions) 

To  Be  Tested.  The  title  of  the  test  plan  for  a component  test  will 
identify  by  name  or  number  the  particular  component  under  test. 
However,  the  test  plan  will  also  describe  the  task  of  that  component 
related  to  the  specification  requirement  that  is  being  implemented. 

If  the  component  satisfies  more  than  one  requirement,  this  will  be 
stated,  and  the  parts  of  the  test  to  demonstrate  each  requirement 
will  be  clearly  identified. 

c.  Selection  of  Validation  Methods.  Validation  will  be  by  means  of 
inspection,  analysis,  demonstration,  or  usage. 

d.  Types  and  Sources  of  Acceptance  Criteria  and  Tolerances.  Acceptance 
criteria  may  be  quantitative  (e.g.,  accuracy  of  results  or  speed  of 
operations)  or  qualitative  (e.g.,  legibility  and  understandabi lity 
of  output).  The  sources  of  criteria  in  the  quantitative  case  should 
be  drawn  from  benchmark  results  from  existing  operations  which  are 
to  be  supplied  by  AFGWC.  Qualitative  criteria  will  have  emanated 
from  the  system  specification. 

e.  Test  Tools.  Test  tools  will  be  selected  to  provide: 

1)  Accurate  listing  of  input  data  for  each  test  case. 

2)  Means  of  exhibiting  data  base  integrity. 

3)  Execution  frequency  and  time  consumption  of  tests. 

4)  Fault  location  (e.g.,  dumps  or  traces). 

5)  Complete  presentation  bf  output  results. 
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f.  Test  Data  Requirements.  The  media,  formats,  ranges,  and  volume  of 
test  data  will  be  specified,  as  well  as  the  sources  of  data. 

g.  Test  Activities  Scheduling.  Each  activity  for  each  test  or  set  of 
tests  within  the  test  plan  will  be  scheduled.  Emphasis  will  be  placed 
upon  the  need  dates  for  test  tools  or  test  data,  particularly  in  cases 
where  test  data  or  reviews  involve  AFGWC.  Subsystem  tests  must  be 
scheduled  in  accordance  with  the  integrated  system  testing  schedule. 

h.  Test  Plan  Review.  Test  plans  will  be  reviewed  for  acceptability  and 
adequacy  by  AFGWC.  When  these  reviews  have  been  successfully  com- 
pleted, the  test  plan  will  provide  a basis  for  the  development  for 
the  test  procedures. 

4.5.2  Test  Procedure  Development 

The  test  procedures  will  provide  a detailed  step-by-step  scenario  of  the  test- 
ing by  which  all  hardware  and  software  will  be  validated. 

a.  Test  Tools  Acquisition.  The  test  tools  and  equipment  configurations 
that  are  required  will  be  specified,  since  successful  testing  will 
depend  upon  these  being  "up  and  running"  for  the  start  of  testing. 

b.  Test  Data  Generation.  If  test  data  generation  is  required,  that 
task  will  be  initiated  immediately  after  the  approval  of  the  test 
plan  to  make  certain  that  the  test  data  will  be  available. 

c.  Test  Case  Design.  Test  cases  will  be  designed  to  demonstrate  for 
each  component  or  subsystem  the  acceptability  of  logic,  computations, 
data  handling,  interfaces,  and  data  base  integrity. 

d.  Acceptance  Criteria  and  Tolerances  Specifications.  Utilizing  the 
sources  and  techniques  to  be  found  in  the  test  plan,  acceptance 
criteria  will  be  specified  unambiguously  for  each  test  case,  and  in 
those  cases  where  the  criteria  are  quantitative,  tolerances  that  will 
define  the  range  of  acceptable  performance  will  be  provided. 
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e.  Test  Procedures  Review.  Test  procedures  will  be  reviewed  for  their 
acceptability  and  accuracy  by  AF6WC.  Upon  the  successful  completion 
of  these  reviews,  these  test  procedures  will  provide  a scenario  for 
the  testing  to  follow,  and  will  make  up  a portion  of  the  documenta- 
tion to  be  delivered  with  the  product. 


4.5.3  Testing 

Tests  may  be  executed  In  any  convenient  order.  However,  when  checkout  of  all 
test  cases  is  complete,  the  entire  test  procedure  scenario  will  be  rerun  in 
documented  sequence.  This  rerun  will  be  monitored  by  AFGWC. 

a.  Error  Correction.  Errors  in  component  will  be  corrected  by  the 
vendor  responsible  for  the  component,  and  the  component  with  modifica- 
tions will  be  retested  by  the  vendor.  If  design  errors  are  encountered, 
they  will  be  documented  by  the  test  team  and  directed  to  AFGWC.  AFGWC 
will  resolve  all  design  errors. 

b.  Test  Results.  When  the  completion  scenario  of  the  tests  procedure 
has  been  successfully  completed  as  documented,  a copy  of  the  test 
output  is  reserved  so  that  it  will  be  available  along  with  the  test 
procedure. 

4.5.4  Performance  Analysis 

The  primary  purpose  of  the  test  report  is  to  evaluate  the  performance  of  the 
system  against  the  criteria  established  in  the  test  procedures.  The  test 
output  will  be  liberally  annotated  and  tabbed  for  subsequent  reference,  and 
will  serve  as  a part  of  the  test  report  along  with  a written  synopsis  of  the 
analysis. 


